Re: [00/17] Large Blocksize Support V3

[William Lee Irwin III]

On Sat, 28 Apr 2007 10:04:08 +0200 Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> 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.

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


-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/