[lkml]   [2007]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 2/2] cpusets: add interleave_over_allowed option
    > Yes, when a task with MPOL_INTERLEAVE has its cpuset mems_allowed expanded 
    > to include more memory. The task itself can't access all that memory with
    > the memory policy of its choice.

    That much I could have guessed (did guess, actually.)

    Are you seeing this in a real world situation? Can you describe the
    situation? I don't mean just describing how it looks to this kernel
    code, but what is going on in the system, what sort of job mix or
    applications, what kind of users, ... In short, a "use case", or brief
    approximation thereto. See further:

    I have no need of a full blown use case; just a three sentence
    mini-story should suffice. But it should (if you can, without
    revealing proprietary knowledge) describe a situation you have
    actual need of addressing.

    > So my change allows those tasks that have already expressed the
    > desire to interleave their memory with MPOL_INTERLEAVE to always
    > use the full range of memory available that is dynamically changing
    > beneath them as a result of cpusets.

    Yup, that it does. Note that it is a special case -- "the full range",
    not any application controlled specific subset thereof, short of
    reissuing set_mempolicy() calls anytime that the applications cpuset
    'mems' changes.

    > The only other way to support such a feature is through a modification to
    > mempolicies themselves, which Lee has already proposed. The problem with
    > that is it requires mempolicy support for cpuset cases and modification to
    > the set_mempolicy() API.

    Do you have a link to what Lee proposed? I agree that a full general
    solution would seem to require a new or changed set_mempolicy API,
    which may well be more than we want to do, absent a more compelling
    "use case" requiring it than we have now.

    > I find it hard to believe that a single cpuset with a single
    > memory_spread_user boolean is going to include multiple tasks that
    > request interleaved mempolicies over differing nodes within the
    > cpuset's mems_allowed. That, to me, is the special case.

    That may well be, to you. To me, pretty much -all- uses of
    set_mempolicy() are special cases ;). I have no way of telling
    whether or not there are users who would require multiple tasks
    in the same cpuset to have different interleave masks, but since
    the API clearly supports that (except when changing cpuset 'mems'
    settings mess things up), I have been presuming that somewhere in
    the universe, such users exist or might come to exist.

    I won't rest till it's the best ...
    Programmer, Linux Scalability
    Paul Jackson <> 1.925.600.0401
    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: 2007-10-26 04:33    [W:0.036 / U:10.164 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site