[lkml]   [2007]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [00/17] Large Blocksize Support V3
    Nick Piggin writes:

    > For the TLB issue, higher order pagecache doesn't help. If distros

    Oh? Assuming your hardware is capable of supporting a variety of page
    sizes, and of putting a page at any address that is a multiple of its
    size, it should help, potentially a great deal, as far as I can see.
    I'm thinking in particular of machines that have software-loaded
    fully-associative TLBs and support a lot of page sizes, e.g.
    4kB * 4^n for n = 0 up to 8 or so, like some embedded powerpc chips.

    It's not as simple on 64-bit powerpc with the hash table of course,
    because the page size is chosen at the segment (256MB) level,
    restricting where we can put 64k and 16M pages to some degree.

    > ship with a 4K page size on powerpc, and use some larger pages in
    > the pagecache, some people are still going to get angry because
    > they wanted to use 64K pages... But I agree 64K pages is too big
    > for most things anyway, and 16 would be better as a default (which
    > hopefully x86-64 will get one day).

    Even 16k is going to bloat the page cache, and some people will
    complain. One way that x86-64 could do 16k pages is by still indexing
    the PTE page in units of 4k, but then have an indicator in the PTE
    that this is a 16k page. Thus a 16k page would occupy 4 consecutive
    PTEs, but once it was loaded into the TLB, a single TLB entry would
    map the whole 16k. That would give the expanded TLB reach and allow
    4k and 16k pages to be intermixed freely.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-04-27 14:17    [W:0.020 / U:2.112 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site