Re: slub-i386-support.patch

[William Lee Irwin III]

On Thu, 10 May 2007, William Lee Irwin III wrote:
>> This is wrong; pgd's are smaller than PAGE_SIZE on PAE. Burning lowmem
>> like this is very, very bad for such systems. pmd_cache is rather
>> trivial to convert to quicklists, since all it does is zero pages. I
>> still don't approve of even the !SHARED_KERNEL_PMD case using PAGE_SIZE
>> -sized pgd's. Xen should really be fixed to avoid requiring guests to
>> have recursive pagetables or whatever it's doing.

On Thu, May 10, 2007 at 01:35:25PM -0700, Christoph Lameter wrote:
> But the Xen guys need the full sized pgd?

Xen is not mandatory as it now stands. Also, I intend to fix up Xen
at some point so it doesn't need this.


On Thu, 10 May 2007, William Lee Irwin III wrote:
>> This comment deletion is bogus, as the locking scheme has not changed.

On Thu, May 10, 2007 at 01:35:25PM -0700, Christoph Lameter wrote:
> The interaction with SLAB has changed with the conversion to
> quicklists. AFAIK Manfred's suggestions were due to the use of the
> slab allocator to manage pgds.

The suggestion was to keep cached preconstructed pgd's on a list for
pageattr.c to traverse instead of the mmlist. The quicklist code
retains that list (in fact, even for the PAE shared kernel pmd case
where it's not necessary) despite it being a different allocator, so
manfred's suggestion remains implemented.

The alternative was 64-bit generation numbers incremented at the time
of change_page_attr(). If generation numbers were used, it would be
possible to dispose of the list altogether. Given the awkwardness of
the list maintenance for Xen, it may be worth using them now. PAE
pgd's could merely double in size to maintain those for the unshared
kernel pmd case, and remain 32B otherwise. Full PAGE_SIZE -sized pgd's
for 2-level pagetables could distribute the generation number across
page->index and page->private, or any other fields available.


-- 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/