Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758943Ab3FCTj2 (ORCPT ); Mon, 3 Jun 2013 15:39:28 -0400 Received: from a9-74.smtp-out.amazonses.com ([54.240.9.74]:42630 "EHLO a9-74.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756229Ab3FCTjX (ORCPT ); Mon, 3 Jun 2013 15:39:23 -0400 X-Greylist: delayed 1144 seconds by postgrey-1.27 at vger.kernel.org; Mon, 03 Jun 2013 15:39:23 EDT Date: Mon, 3 Jun 2013 19:20:17 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: JoonSoo Kim cc: Steven Rostedt , Joonsoo Kim , LKML , RT , Thomas Gleixner , Clark Williams , Pekka Enberg Subject: Re: [RT LATENCY] 249 microsecond latency caused by slub's unfreeze_partials() code. In-Reply-To: Message-ID: <0000013f0b7b993c-35844ed2-81be-4146-ab3c-6c803006576b-000000@email.amazonses.com> References: <1364010673.6345.156.camel@gandalf.local.home> <1364227073.6345.182.camel@gandalf.local.home> <1364228039.6345.183.camel@gandalf.local.home> <0000013da2ace21a-9e87fe8a-75c2-4b7c-b5e1-37ad196ce012-000000@email.amazonses.com> <1364234613.6345.184.camel@gandalf.local.home> <0000013da2ce20f8-0e3a64ef-67ed-4ab4-9f20-b77980c876c3-000000@email.amazonses.com> <1364236355.6345.185.camel@gandalf.local.home> <20130327025957.GA17125@lge.com> <1364355032.6345.200.camel@gandalf.local.home> <20130327061351.GB17125@lge.com> <0000013db20ca149-0064fbb8-2f81-4323-9095-a38f6abb79c5-000000@email.amazonses.com> <1369751967.15552.12.camel@gandalf.local.home> <0000013eec62261a-77052f34-f1cb-41b2-ae90-7575a2d0472c-000000@email.amazonses.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 2013.06.03-54.240.9.74 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1003 Lines: 21 On Tue, 4 Jun 2013, JoonSoo Kim wrote: > And I re-read Steven initial problem report in RT kernel and find that > unfreeze_partial() do lock and unlock several times. This means that > each page in cpu partial list doesn't come from same node. Why do we > add other node's slab to this cpu partial list? This is also not good > for general case. How about considering node affinity in __slab_free()? > IMHO, if we implement this, Steven's problem can be solved. We may need the other nodes pages if we consistently allocate from there. __slab_alloc() ensures that only pages from the correct node are used. It will drop pages that do not come from the proper nodes. Filtering in __slab_free would mean that we cannot improve performance on remote frees. -- 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/