Re: [00/17] Large Blocksize Support V3

[Nick Piggin <nickpiggin@yahoo.com.au>]

Eric W. Biederman wrote:
> Christoph Lameter <clameter@sgi.com> 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
> > 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 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/