Messages in this thread | | | Date | Sat, 2 Oct 2004 20:19:33 -0700 | From | Paul Jackson <> | Subject | Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement |
| |
Peter writes: > > The way I see it you just replace the task's affinity mask with a > pointer to its "CPU set" which contains the affinity mask shared by > tasks belonging to that set ...
I too like this suggestion. The current duplication of cpus_allowed and mems_allowed between task and cpuset is a fragile design, forced on us by incremental feature addition and the need to maintain backwards compatibility.
> A possible problem is that there may be users whose use of the current > affinity mechanism would be broken by such a change. A compile time > choice between the current mechanism and a set based mechanism would be > a possible solution.
Do you mean kernel or application compile time? The current affinity mechanisms have enough field penetration that the kernel will have to support or emulate these calls for a long period of deprecation at best.
So I guess you mean application compile time. However, the current user level support, in glibc and other libraries, for these calls is sufficiently confused, at least in my view, that rather than have that same API mean two things, depending on a compile time switch, I'd rather explore (1) emulating the existing calls, just as they are, (2) adding new calls that are try these API's again, in line with our kernel changes, and (3) eventually deprecate and remove the old calls, over a multi-year period.
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.650.933.1373 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |