On Sat, 28 Apr 2007 07:09:07 -0700 William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> On Sat, 28 Apr 2007 10:04:08 +0200 Peter Zijlstra <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
