[lkml]   [2007]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 2/2] cpusets: add interleave_over_allowed option
    Lee wrote:
    > > Indeed, if there was much such usage, I suspect they'd
    > > be complaining that the current kernel API was borked, and
    > > they'd be filing a request for enhancement -asking- for just
    > > this subtle change in the kernel API's here. In other words,
    > > this subtle API change is a feature, not a bug ;)
    > Agreed.

    Hmmm ... put your thinking hat for my next comment ...

    I could do one of two things in mm/mempolicy.c:
    B1) continue accepting nodemasks across the set_mempolicy and mbind
    system call APIs that are just like now (only nodes in the current
    tasks cpuset matter), but then remember what was passed in, so that
    if the tasks cpuset subsequently shrank down and then expanded
    again back to its original size, they would end up with the same
    memory policy placement they first had, or
    B2) accept nodemasks as if relative to the entire system, regardless
    of what cpuset they were in at the moment (all nodes in the system
    matter and can be specified.)

    If I did B1, then that's just a subtle change in the API, and what
    you agreed to above holds.

    If I did B2, then that's a serious change in the way that nodes
    are numbered in the nodemasks passed into mbind and set_mempolicy,
    from being only nodes that happen to be in the tasks current cpuset,
    to being nodes relative to all possible nodes on the system.

    We need B2, I think. Otherwise, if a job happens to be running in
    a shrunken cpuset, it can't request what memory policy placement
    it wants should it end up in a larger cpuset later on. With B1, we
    would continue to have the timing dependencies between when a task
    is moved between different size cpusets, and when it happens to issue
    mbind/set_mempolicy calls.

    But B2 is an across the board change in how we number the nodes
    passed into mbind and set_mempolicy. That is in no way an upward
    compatible change.

    I am strongly inclined toward B2, but it must be a non-default optional
    mode, at least for a while, perhaps a long while.

    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-29 21:01    [W:0.020 / U:7.300 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site