Messages in this thread | | | Date | Tue, 11 Mar 2008 01:57:11 -0500 | From | Paul Jackson <> | Subject | Re: [PATCH 1/2] cpuset: cpuset irq affinities |
| |
Max K wrote: > this could also provide the desired semantics.
Could you spell out what you mean by "the desired semantics" ?
I don't see any Documentation or much comments, which would help understand this. It helps to describe both what has changed, and, from the top, the why, what and how of what you're doing, in part as Documentation or code comments, for the benefit of future readers.
Did you see my discussion of this with Peter on March 6 and 7 in the lkml "[RFC/PATCH] cpuset: cpuset irq affinities" thread? This latest patch of yours seems, offhand, to predate that discussion.
I don't see any explanation of what locking is needed when.
What semantics to you impose on irqs in overlapping cpusets, which would seem to lead to conflicting directives as to whether one set or another of irqs was to be applied to the CPUs in the overlap?
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.940.382.4214
| |