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

[Paul Jackson <pj@sgi.com>]

Ingo wrote:
> 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.

Arrghh ...

I'm confused, on several points.

I've discussed this some with my SGI colleagues, and think I understand
where they are coming from.

But I can't make sense of your recommendation, Ingo.

I don't yet see why you find this more natural or robust, but let me
deal with some details first.

I don't recall Andrew observing ugliness in a sysadmin configuring
a kernel slab.  I recall him asking to add such ugliness.  My proposal
just had a "memory_spread" boolean, which asked for the kernel (1) to
spread memory, at least getting the big kinds of allocations done from
the apps perspective, within the kernel, but (2) leaving the user
address space pages to be placed by the default node-local policy.
No mention there of slab caches.  It was Andrew who wanted to add
such details.

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.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401
-
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/