Andrew Morton wrote:
quoted text
> On Thu, 17 Apr 2008 12:11:36 +0200 Andi Kleen <andi@firstfloor.org> wrote:
> 
>> Andrew Morton <akpm@linux-foundation.org> writes:
>>> Does it really really really need to consume one of our few remaining page
>>> flags?  We'll be in a mess when we run out.
>> No we're not. Just the (imho always misguided) "encode zone/node number 
>> into flags" optimization has to be removed again or made 64bit only.
>> Then there will be plenty of flags again.
> 
> hm.  Or we add a new nid&zone field to the pageframe for 32bit NUMA.  Just
> don't tell Paul Mundt ;)

Most (all?) NUMA archs have some way to get from phys->nid. Getting from
pfn->nid is then easy.

Originally this was all optimized for text size when this stuff was
still inlined, but at some point they were all out of lined anyways
(unless on FLAT iirc) so a lot of the old design decisions became obsolete.

BTW I should disclose that my mask allocator that I'm still planning
to push needs one flag bit on 32/64bit and another one on 64bit
(for swiotlb)

quoted text
> 
> Need to work out what's going on with ia64's use of the upper 32 bits too. 
> I have a feeling it's using less than it used too but at 3AM I can't be
> assed working it out.
> 
>> Really I see no real reason this can't be done with a small hash table
>> again like x86-64 originally did.
> 
> How did that work?  A pfn->zone-id hash table would be huge?

Sorry i meant it used the hash table to look up the node. In fact
that code is still in there, although used less because a lot of these
lookups are resolved from the flags.

Once you have the node from the pfn it is a at most three range checks
to get to the zone (usually less). The most efficient way to do that is
to just open code it in code.

-Andi

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/