Re: [PATCH 1/5] cpuset memory spread basic implementation

[David Chinner <dgc@sgi.com>]

On Tue, Feb 07, 2006 at 01:19:02AM +0100, Ingo Molnar wrote:
> 
> * Paul Jackson <pj@sgi.com> wrote:
> 
> > First it might be most useful to explain a detail of your proposal 
> > that I don't get, which is blocking me from considering it seriously.
> > 
> > I understand mount options, but I don't know what mechanisms (at the 
> > kernel-user API) you have in mind to manage per-directory and per-file 
> > options.
> 
> well, i thought of nothing overly complex: it would have to be a 
> persistent flag attached to the physical inode. Lets assume XFS added 
> this - e.g. as an extended attribute. That raw inode attribute/flag gets 
> inherited by dentries, and propagates down into child dentries.

XFS already has inheritable inode attributes, and they work in a
different (conflicting) manner. Currently when you set certain
attributes on a directory inode, then all directories and files
created within the directory inherit a certain attribute(s) at create
time. See xfsctl(3).

Having no flag set means to use the filesystem default, not "use
the parent config". Flags are also kept on the inode, not the
dentries. We should make sure that the interfaces do
not conflict.

>  - default: the vast majority of inodes would have no flag set
> 
>  - some would have a 'cache:local' flag
> 
>  - some would have a 'cache:global' flag

Easy to add to XFS and to propagate back to the linux inode if
you use the current semantics that XFS supports. How the
memory allocator works from there is up to you...

Cheers,

Dave.
-- 
Dave Chinner
R&D Software Enginner
SGI Australian Software Group
-
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/