On Friday 03 May 2002 17:17, Martin J. Bligh wrote:
> Andrea apparently wrote:
> > Ah, and of course you could also use 2M pagetables by default to make it
> > more usable but still you would run in some huge ram wastage in certain
> > usages with small files, huge pageins and reads swapout and swapins,
> > plus it wouldn't be guaranteed to be transparent to the userspace
> > binaries (for istance mmap offset fields would break backwards
> > compatibility on the required alignment, that's probably the last
> > problem though). Despite its also significant drawbacks and the
> > complexity of the change, probably the 4M pagetables would be the saner
> > approch to manage more efficiently 64G with only a 800M kernel window.
>
> Though that'd reduce the size of some of the structures, I'd still
> have other concerns (such as tlb size, which is something stupid
> like 4 pages, IIRC), and the space wastage you mentioned. Page
> clustering is probably a more useful technique - letting the existing
> control structures control groups of pages. For example, one struct
> page could control aligned groups of 4 4K pages, giving us an
> effective page size of 16K from the management overhead point of
> view (swap in and out in 4 page chunks, etc).
IMHO, this will be a much easier change than storing mem_map in highmem,
and solves 75% of the problem. It's not just ia32 numa that will benefit
from it. For example, MIPS supports 16K pages in software, which will
take a lot of load off the tlb. According to Ralf, there are benefits
re virtual aliasing as well.
-- Daniel - 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/
This archive was generated by hypermail 2b29 : Tue May 07 2002 - 22:00:20 EST