Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932808AbYBMTSY (ORCPT ); Wed, 13 Feb 2008 14:18:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754749AbYBMTSI (ORCPT ); Wed, 13 Feb 2008 14:18:08 -0500 Received: from smtp-out.google.com ([216.239.33.17]:37831 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758333AbYBMTSG (ORCPT ); Wed, 13 Feb 2008 14:18:06 -0500 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:date:from:x-x-sender:to:cc:subject:in-reply-to: message-id:references:user-agent:mime-version:content-type; b=lTTrkbBPhHIYjSBtsj3O3WdQvCjMAPqQRYUUiKNCk1z0RgxZ989UafAeY7htuKVc3 yE5h9YULiWLleR9EjtMWA== Date: Wed, 13 Feb 2008 11:17:07 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Lee Schermerhorn cc: Paul Jackson , akpm@linux-foundation.org, clameter@sgi.com, ak@suse.de, linux-kernel@vger.kernel.org, mel@csn.ul.ie Subject: Re: [patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag In-Reply-To: <1202929511.4978.88.camel@localhost> Message-ID: References: <1202862136.4974.41.camel@localhost> <20080212215242.0342fa25.pj@sgi.com> <20080212221354.a33799f2.pj@sgi.com> <20080213020344.45c9d924.pj@sgi.com> <1202918501.4978.38.camel@localhost> <1202929511.4978.88.camel@localhost> User-Agent: Alpine 1.00 (DEB 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1968 Lines: 41 On Wed, 13 Feb 2008, Lee Schermerhorn wrote: > > Yeah, it gets tricky. I'm not too sure about only pulling the mode and > > flags apart at mpol_new() time because perhaps, in the future, there will > > be flag and mode combinations that are only applicable for set_mempolicy() > > and not for mbind(), for example. I can imagine that someday we may add a > > flag that applies only to a task mempolicy and not to a VMA mempolicy. > > True. Altho' at such a time, I'd probably argue for testing for and > rejecting invalid mode/flag combinations in the respective > functions :-). > Yeah, and that would require the modes and flags to be split apart in sys_set_mempolicy() and sys_mbind() or at least in do_set_mempolicy() or do_mbind(). So if we see the possibility that we want to test for mode and flag combinations that perhaps differ between the set_mempolicy() and mbind() case, we have to do it in either of those two places. I think we should do it there, as early as possible, like I did in my first patchset. > OK. I'm "caving"... :-) Different views of consistency. But, > eventually, I hope we can replace the separate mode[, flags] and > nodemask in the 'sb_info with a mempolicy and keep the details of modes, > flags, etc. internal to mempolicy.c. > I agree, I think keeping all of these implementation details inside mm/mempolicy.c is the best practice. We'll still need to expose some of the details, such as the parsing of '=static' in the tmpfs mount option to add the MPOL_F_STATIC_NODES flag to the policy, but situations like that should be rare. For extendability, I agree that the struct shmem_sb_info member should be a pointer to a mempolicy and not an int. David -- 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/