[lkml]   [2007]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [00/17] Large Blocksize Support V3
    Paul Mackerras wrote:
    > 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.

    That's a little bit more than just the higher order pagecache patch.
    But I don't know if that would be impossible to do with the "attempt
    to allocate contiguous pagecache" approach either. Or if it would be
    worthwhile to support.

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

    I guess any page size bloats the pagecache relative to something
    smaller :) But 4K doesn't seem to be proving too much problem for
    x86 and I'm not talking about an actual implementation coming up,
    but just a size that would make sense in future (and probably last
    for a long time).

    SUSE Labs, Novell Inc.
    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:39    [W:4.361 / U:0.196 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site