Re: [patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag

[David Rientjes]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/