* Christoph Lameter <[email protected]> wrote:
> 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.
it's a feature, not a weird effect! Under the VFS-driven scheme, if two
projects (one 'local' and one 'global') can access the same (presumably
big) file, then the sysadmin has to make up his mind and determine which
policy to use for that file. The file will either be local, or global -
consistently.
[ I dont think most policies would be set on the file level though -
directory level seems sufficient. E.g. /usr and /tmp would probably
default to 'local', while /home/bigproject1/ would default to
'global', while /home/bigproject2/ would default to 'local' [depending
on the project's need]. Single-file would be used if there is an
exception: e.g. if /home/bigproject3/ defaults to 'local', it could
still mark /home/bigproject3/big-shared-db/ as 'global'. ]
with the per-cpuset policy approach on the other hand it would be
non-deterministic which policy the file gets allocated under: whichever
cpuset first manages to touch that file. That is what i'd call a weird
and undesirable effect. This weirdness comes from the conceptual hickup
of attaching the object-allocation policy to the workload, not to the
file objects of the workload - hence conflicts can arise if two
workloads share file objects.
> What happens if a filesystem is exported? Is the spreading also
> exported?
what do you mean? The policy matters at the import point, so i doubt
knfsd would have to be taught to pass policies around. But it could do
it, if the need arises. Alternatively, the sysadmin on the importing
side can/should set the policy based on the needs of the application
using the imported file objects. It is that box that is doing the
allocations after all, not the server. In fact the same filesystem could
easily be 'global' on the serving system, and 'local' on the importing
system.
Ingo
-
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]
