[lkml]   [2006]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/5] cpuset memory spread basic implementation
> >  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 won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <> 1.925.600.0401
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-02-06 06:53    [W:0.129 / U:2.204 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site