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

[Christoph Lameter]

On Mon, 6 Feb 2006, Ingo Molnar wrote:

> yes. And it seems that for the workloads you cited, the most natural 
> direction to drive the 'spreading' of resources is from the VFS side.  
> That would also avoid the problem Andrew observed: the ugliness of a 
> sysadmin configuring the placement strategy of kernel-internal slab 
> caches. It also feels a much more robust choice from the conceptual POV.

A sysadmin currently simply configures the memory policy or cpuset policy. 
He has no knowledge of the underlying slab.

Moving this to the VFS will give rise to all sorts of weird effects. F.e. 
doing a grep on a file will spread the pages all over the system. 
Performance will drop for simple single thread processes.

What happens if a filesystem is exported? Is the spreading also exported?

Seems that the allocation policy is application dependend and not related 
to file access. Also some of the slabs have no underlying files that 
could determine their allocation strategy (network subsystem etc). 

AFAIK the cleanest solution is that an application controls its memory
allocation policy (which has been available for a long time via memory 
policies which even in early 2.6.x controlled the slab page allocation 
policy).

Cpusets are simply a convenience so that a larger groups of applications 
can implement the same policy and may allow one to avoid running numactl 
or modifying an existent application.
-
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/