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 <[email protected]> 1.925.600.0401
-
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]
