On Wed, Sep 17, 2025 at 8:22 AM Jason Gunthorpe <j...@nvidia.com> wrote: > > On Tue, Sep 16, 2025 at 07:50:16PM -0700, Jason Miu wrote: > > + * kho_order_table > > + * +-------------------------------+--------------------+ > > + * | 0 order| 1 order| 2 order ... | HUGETLB_PAGE_ORDER | > > + * ++------------------------------+--------------------+ > > + * | > > + * | > > + * v > > + * ++------+ > > + * | Lv6 | kho_page_table > > + * ++------+ > > I seem to remember suggesting this could be simplified without the > special case 7h level table table for order. > > Encode the phys address as: > > (order << 51) | (phys >> (PAGE_SHIFT + order))
Why 51 and not 52, this limits to 63bit address space, is it not? > > Then you don't need another table for order, the 64 bits encode > everything consistently. Order can't be > 52 so it is > only 6 bits, meaning the result fits into at most 57 bits. > Hi Jason, Nice packing. That's a really clever bit-packing scheme to create a unified address space. I like the idea, but I'm trying to find the benefits compared to the current per-order tree approach. 1. Packing adds a slight performance overhead for higher orders. With the current approach, preserving higher order pages only requires a 3/4-level page table. With bit-packing proposal we will always have extra loads during preserve/unpreserve operations. 2. It also adds insignificant memory overhead, as extra levels will have a couple extra pages. 3. It slightly complicates the logic in the new kernel. Instead of simply iterating a known tree for a specific order, the boot-time walker would need to reconstruct the per-order subtrees, and walk them. Perhaps I'm missing a key benefit of the unified tree? The current approach might not be as elegant as having everything packed into the same page table but it seems to be OK to me, and easy to understand. Pasha
