Re: [PATCH] anobjrmap 1/6 objrmap

[William Lee Irwin III]

On Wed, Mar 24, 2004 at 05:21:16PM +0100, Andrea Arcangeli wrote:
> it's one of the -mm patches probably that boosts those bits (the
> cost page_add_rmap and the page faults should be the same with both
> anon-vma and anonmm). as for the regression, the pgd_alloc slowdown is
> the unslabify one from andrew that releases 8 bytes per page in 32bit
> archs and 16 bytes per page in 64bit archs.
> My current page_t is now 36 bytes (compared to 48bytes of 2.4) in 32bit
> archs, and 56bytes on 64bit archs (hope I counted right this time, Hugh
> says I'm counting wrong the page_t, methinks we were looking different
> source trees instead but maybe I was really counting wrong ;).

Don't confuse unslabify and the ->list removal. The ->list removal went
around insisting the known universe stop using ->lru because of the
relatively arbitrary choice that slab.c use ->lru. The unslabify patch
attempts to update one user of ->lru by backing out the code using it.
Do note that non-list-heads like ->index, ->private, or ->mapping are
also unused on slab pages, and could have saved some pain for this
former user of ->list had they been chosen.


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