> > never? :) i'm eyeing with the PPro 2MB page stuff, it's probably buggy and
> > seems to be discontinued, but is interesting nevertheless ;)
>
> The ppro 2M and 4M extensions aren't general-purpose enough to make it
> useful to consider a "page size". Even when you enable the silly
> three-level page tables, the basic page size if 4kB.
hm, if you dont make it a PAGE_TABLE type in the second level page table
then i thought it would point to a (2mb aligned) physical page, and this
mapping would be visible from user-space too if flagged properly. The 2mb
alignment thing is serious, but maybe it's possible to have
number-crunching servers operate in such mappings. In some cases TLB
trashing is a serios offender. Although the number of 'bigpage' TLBs is
usually lower than the number of 4K TLBs, so the effect might be
contraproductional.
obviosly on boxes with 16K L1 cache and serios L2 cache penalties it
doesnt make a big difference, but on boxes with megabytes of low-latency
on-chip cache (Xeon), the number of TLBs is relatively low and might
become a bottleneck. (and we pay for the miss even if the page table is
cached)
> The 2M and 4M versions can be useful for specific cases (we obviously
> already use the 4M pages for the kernel itself), but thinking that they
> should be exported as a supported page size to user mode is just silly.
i considered 'per-process' pagesizes. (or rather, per-executable pagesize)
Making it boot-time is silly because the difference between 4k and 2m is
so huge. Making it some special feature is hairy because we really want
all the executable mappings and data mappings be in 2mb pages.
> We could silently and magically use them for certain things (doing a
> mmap(/dev/mem) using them for XFree86 comes to mind), but while I've often
> heard the claims that TLB miss time makes a difference to graphics work, I
> don't actually believe it for a second.
if you draw a vertical line through a framebuffer, the ~20 cycles per TLB
miss will make a difference. (a truecolor framebuffer is about 4k per line
on resolution near 1000, so we need a new TLB for every new line. Thats
700+ TLB misses for a single line) But this is less and less of an issue,
most cards are accelerated properly, and framebuffer rendering in Quake is
done on scanline basis.
But it would be a neat feature nevertheless, unfortunately exporting 4MB
pages to ring 3 user-space doesnt seem to work (i've tried), only ring 0
is supposed to see those mappings.
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/