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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
