Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752285AbZCJEGm (ORCPT ); Tue, 10 Mar 2009 00:06:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750715AbZCJEGd (ORCPT ); Tue, 10 Mar 2009 00:06:33 -0400 Received: from waste.org ([66.93.16.53]:50604 "EHLO waste.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750698AbZCJEGc (ORCPT ); Tue, 10 Mar 2009 00:06:32 -0400 Subject: Re: [patch -mm] cpusets: add memory_slab_hardwall flag From: Matt Mackall To: David Rientjes Cc: KOSAKI Motohiro , Christoph Lameter , Andrew Morton , Pekka Enberg , Paul Menage , Randy Dunlap , linux-kernel@vger.kernel.org In-Reply-To: References: <20090310102926.A47E.A69D9226@jp.fujitsu.com> Content-Type: text/plain Date: Mon, 09 Mar 2009 23:05:54 -0500 Message-Id: <1236657954.4192.523.camel@calx> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1565 Lines: 37 On Mon, 2009-03-09 at 19:01 -0700, David Rientjes wrote: > On Tue, 10 Mar 2009, KOSAKI Motohiro wrote: > > > That's pointless. > > Again, any fastpath modification should have reasonable reason. > > We are looking for your explanation. > > > > The fastpath modification simply checks if the hardwall bit is set in the > allocating task's cpuset flags. If it's disabled, there is no additional > overhead. Ok, I for one understand perfectly the desire for this feature. But we are still extremely sensitive to adding potential branches to one of the most important fast-paths in the kernel, especially for a feature with a fairly narrow use case. We've invested an awful lot of time into micro-optimizing SLAB (by rewriting it as SLUB/SLQB) so any steps backward at this stage are cause for concern. Also, remember 99%+ of users will never care about this feature. For SLOB, I think the code is fine as it stands, but we probably want to be a bit more clever for the others. At the very minimum, we'd like this to be in an unlikely path. Better still if the initial test can somehow be hidden with another test. It might also be possible to use the patching code used by markers to enable the path only when one or more tasks needs it. -- http://selenic.com : development and support for Mercurial and Linux -- 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/