Messages in this thread | | | Date | Tue, 11 Mar 2008 10:25:34 -0700 | From | Max Krasnyansky <> | Subject | Re: [PATCH 1/2] cpuset: cpuset irq affinities |
| |
Paul Jackson wrote: > 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. Paul, can you please comment on 2/2 patch instead. 1/2 is just a resend of the Peter's original patch that I was building on top. So yes it predates that discussion. I used it as the baseline.
> I don't see any explanation of what locking is needed when. There are more comments in 2/2. There is one spot in there where I'm not sure about the locking (look for FIXME comment). Everything else seems to be protected correctly by callback_lock. I may have missed things of course.
> 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? Please take a look at [PATCH 2/2] cpusets: Improved irq affinity handling I'm treating irqs just like tasks (at least I think I'm :).
Max
| |