[lkml]   [2007]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [00/17] Large Blocksize Support V3
    Eric W. Biederman wrote:
    > Christoph Lameter <> writes:

    >>>Right now I don't even want to think about trying to use a swap device
    >>>with a large block size when we are low on memory.
    >>But that is due to the VM (at least Linus tree) having no defrag methods.
    >>mm has Mel's antifrag methods and can do it.
    > This is fundamental. Fragmentation when you multiple chunk sizes
    > cannot be solved without a the ability to move things in memory,
    > whereas it doesn't exist when you only have a single chunk size.

    And even if you can (and you can't always, because the anti-frag is
    only heuristics), then it costs you complexity and overhead to do.

    >>Less meta data to manage does not reduce fsck times? Going from order 0 to
    >>order 2 blocks cuts the metadata to a fourth.
    > I agree that less meta data helps. But switching to extents can reduce the
    > meta data much more, and still doesn't penalize you for small files if
    > you have them.

    Anyway, this is a general large block size issue, and not specifically
    anything to do with large pagecache size.

    >>There are multiple scaling issues in the kernel. What you propose is to
    >>add hack over hack into the VM to avoid having to deal with
    >>defragmentation. That in turn will cause churn with hardware etc
    > No. I propose to avoid all designs that have the concept of
    > fragmentation.

    Yeah. IMO anti-fragmentation and defragmentation is the hack, and we
    should stay away from higher order allocations whenever possible.

    Hardware is built to handle many small pages efficintly, and I don't
    understand how it could be an SGI-only issue. Sure, you may have an
    order of magnitude or more memory than anyone else, but even my lowly
    desktop _already_ has orders of magnitude more pages than it has TLB
    entries or cache -- if a workload is cache-nice for me, it probably
    will be on a 1TB machine as well, and if it is bad for the 1TB machine,
    it is also bad on mine.

    If this is instead an issue of io path or reclaim efficiency, then it
    would be really nice to see numbers... but I don't think making these
    fundamental paths more complex and slower is a nice way to fix it
    (larger PAGE_SIZE would be, though).

    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-26 08:43    [W:0.022 / U:211.216 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site