[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

    * Christoph Lameter <> 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 -

    [ 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

    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 21:45    [W:0.023 / U:71.536 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site