Re: [PATCH 1/2] cpuset: cpuset irq affinities

[Paul Jackson]

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@xxxxxxx> 1.940.382.4214
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/