Greetings,
I have been staying up late thinking about this, so I'm writing to clear
my head.
(and get some sleep in the future)
Background:
Under ia32 Pentium and higher, 3 different MMU page sizes are
available in hardware: 4kB, 4MB & 2MB. Under Alpha (21064), sizes
include 8kB, 4MB for code, 8kB, 64kB, 512kB, and 4MB. Under ia64,
sizes range (in powers of two) from 4kB to 256MB.
Significance: a number of important architectures support multi-sized
pages. For applications with large contiguous code and/or data objects,
this enhanced hardware allows a performance increase. A prerequisite
for using these features is kernel support.
I am unaware of what order of improvement this will allow, but I can
immagine
the pipeline stalls caused on TLB misses: examples: gimp lightens an
entire 64MB image;
a linear scan read-modify-write. This access pattern isn't *so* bad.
The X server mmaps a 32MB area (3dfx) or larger of the video card for
linear frame
buffer/mmio and accesses it in a slightly less that random fashion.
This could benefit much more from
larger pages. Note that this is completely different that MTRR
support. Also consider
that the TLB cache must be flushed and reloaded frequently durring
context switches
under an OS with separate memory areas for each process. The larger the
pages, the
fewer entries which must be reloaded.
Also, not completely unrelated are comments in the kernel 2.3.? slab
allocator
regarding the inabliity of the zoned-buddy allocator to provide more
than
single (or trivially larger) pages for slab-cache. The code which would
request larger pages when it would be more optimal to do so is commented
with 1's hardcoded instead.
Proposed implementation:
Short term: allow a special (temporary) mmap argument or syscall and
support
in fault handlers/page table routines, to allow mmap or non-ram areas
with larger
sized pages. the X server could uses this immediately by adding the
call alongside
the MTRR setting. This avoids swap / mmaped file issues.
Long term: extend the zoned-buddy allocator to include buddy-lists
up to the largest hardware page size; page table and fault handlers,
swap code, etc; massive work just for UP. user-space code
could mmap ANON and get an aligned 4MB area using a single hardware
page...
Egad man! or "stop the madness"?
-
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 : Sat Feb 17 2001 - 16:06:00 EST