linux-kernel - Re: [00/17] Large Blocksize Support V3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 28 Apr 2007 11:26:40 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	William Lee Irwin III <wli@...omorphy.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	David Chinner <dgc@....com>,
	Christoph Lameter <clameter@....com>,
	linux-kernel@...r.kernel.org, Mel Gorman <mel@...net.ie>,
	Jens Axboe <jens.axboe@...cle.com>,
	Badari Pulavarty <pbadari@...il.com>,
	Maxim Levitsky <maximlevitsky@...il.com>
Subject: Re: [00/17] Large Blocksize Support V3

On Sat, 28 Apr 2007 07:09:07 -0700 William Lee Irwin III <wli@...omorphy.com> wrote:

> On Sat, 28 Apr 2007 10:04:08 +0200 Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> >> only 4.4 times faster, and more scalable, since we don't bounce the
> >> upper level locks around.
> 
> On Sat, Apr 28, 2007 at 01:22:51AM -0700, Andrew Morton wrote:
> > I'm not sure what we're looking at here.  radix-tree changes?  Locking
> > changes?  Both?
> > If we have a whole pile of pages to insert then there are obvious gains
> > from not taking the lock once per page (gang insert).  But I expect there
> > will also be gains from not walking down the radix tree once per page too:
> > walk all the way down and populate all the way to the end of the node.
> 
> The gang allocation affair would may also want to make the calls into
> the page allocator batched. For instance, grab enough compound pages to
> build the gang under the lock, since we're going to blow the per-cpu
> lists with so many pages, then break the compound pages up outside the
> zone->lock.

Sure, but...

Allocating a single order-3 (say) page _is_ a form of batching

We don't want compound pages here: just higher-order ones

Higher-order allocations bypass the per-cpu lists

> I think it'd be good to have some corresponding tactics for freeing as
> well.

hm, hadn't thought about that - would need to peek at contiguous pages in
the pagecache and see if we can gang-free them as higher-order pages.

The place to do that is perhaps inside the per-cpu magazines: it's more
general.  Dunno if it would net advantageous though.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/