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

[Andrew Morton <akpm@osdl.org>]

Paul Jackson <pj@sgi.com> wrote:
>
> > >  I'd have thought it would be saner to split these things apart:
> > >  "slab_spread", "pagecache_spread", etc.
> > 
> > This, please.   It impacts the design of the whole thing.
> 
> It was still in my queue to respond to, yes.
> 
> All I am aware that is needed is to distinguish between:
> 
>   (1) application space pages, such as data and stack space,
>       which the applications can page and place under their
>       detailed control, and
> 
>   (2) what from the application's viewpoint is "kernel stuff"
>       such as large amounts of pages required by file i/o,
>       and their associated inode/dentry structures.
> 
> The application space pages are typically anonymous pages
> which go away when the owning tasks exits, while the kernel
> space pages are typically accessible by multiple tasks and
> can stay around long after the initial faulting task exits.
> 
> I prefer to keep the tunable knobs to a minimum.  One boolean
> was sufficient for this.
> 
> Just because a distinction seems substantial from the kernel
> internals perspective, doesn't mean we should reflect that in
> the tunable knobs.  We should have an actual need first, not
> a strawman.
> 
> If there is some reason, or preference, for adding two knobs
> (slab and page) instead of one, I can certainly do it.
> 
> I am not yet aware that such is useful.
> 

I suspect that you'll find different workload patterns and sequences which
cause similar regressions in the future.  It'd be useful to sit down and
try to think of some and try them out.

I think the bottom line here is that the kernel just cannot predict the
future and it will need help from the applications and/or administrators to
be able to do optimal things.  For that, finer-grained one-knob-per-concept
controls would be better.