Andrew Morton wrote:
> Matthew Dobson <[email protected]> wrote:
>
>>Currently we keep track of a pages node & zone in the top 8 bits (on
>>32-bit arches, 10 bits on 64-bit arches) of page->flags. We typically
>>compute the field as follows:
>> node_num * MAX_NR_ZONES + zone_num = 'nodezone'
>>
>>It's non-trivial to break this 'nodezone' back into node and zone
>>numbers. This patch modifies the way we compute the index to be:
>> (node_num << ZONE_SHIFT) | zone_num
>>
>>This makes it trivial to recover either the node or zone number with a
>>simple bitshift. There are many places in the kernel where we do things
>>like: page_zone(page)->zone_pgdat->node_id to determine the node a page
>>belongs to. With this patch we save several pointer dereferences, and
>>it all boils down to shifting some bits.
>
>
> This conflicts with (is a superset of)
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm5/broken-out/ZONE_SHIFT-from-NODES_SHIFT.patch
>
> I suspect you've sent a replacement patch, yes? If Jesse is OK with the
> new patch I'll do the swap, thanks.
Jesse had acked the patch in an earlier itteration. The only thing
that's changed is some line offsets whilst porting the patch forward.
Jesse (or anyone else?), any objections to this patch as a superset of
yours?
Cheers!
-Matt
On Mon, Jan 05, 2004 at 01:22:57PM -0800, Matthew Dobson wrote:
> Jesse had acked the patch in an earlier itteration. The only thing
> that's changed is some line offsets whilst porting the patch forward.
>
> Jesse (or anyone else?), any objections to this patch as a superset of
> yours?
No objections here. Of course, you'll have to rediff against the
current tree since that stuff has been merged for awhile now. On a
somewhat related note, Martin mentioned that he'd like to get rid of
memblks. I'm all for that too; they just seem to get in the way.
Jesse
On Mon, Jan 05, 2004 at 01:22:57PM -0800, Matthew Dobson wrote:
> Jesse had acked the patch in an earlier itteration. The only thing
> that's changed is some line offsets whilst porting the patch forward.
>
> Jesse (or anyone else?), any objections to this patch as a superset of
> yours?
No objections here. Of course, you'll have to rediff against the
current tree since that stuff has been merged for awhile now. On a
somewhat related note, Martin mentioned that he'd like to get rid of
memblks. I'm all for that too; they just seem to get in the way.
Jesse