Re: Reverting per-cpuset "system" (IRQ affinity) patch

[Max Krasnyanskiy <maxk@qualcomm.com>]

Paul Jackson wrote:
> Ingo wrote:
>> none of this is upstream yet (nor is any of this even near to being 
>> ready for upstream), so there's nothing to revert.
> 
> I thought one of the earlier patches (Max's, perhaps) that we considered
> in this discussion back in Feb or March -did- end up close to traveling
> upstream, via the sched-devel tree going into linux-next, or some such.
> 
> However I can't claim to understand what (almost) went down there as
> well as Andrew or Stephen hopefully do.
> 
> 
>> Paul/Peter/Max, what's the current agreed-upon approach
> 
> Well ... we don't have an agreed on approach yet ;)
> 
> 
>> to merge these physical resource isolation features into cpusets
>> intelligently while still keeping the whole thing as usable and
>> practical to down-to-earth sysadmins as possible? That is the issue
>> that is blocking this whole topic from progressing.
> 
> Well, yeah, everyone wants "simple".  But that tends to degrade into
> each of us insisting that whatever we don't appreciate need for in the
> other guys proposal be removed.  That way lies not progress.

Yeah, unfortunately we did not make much progress. Partly because of 
disagreements and party because I was on a longish vacation and did not get a 
chance to push things forward. Now I'm back.

At this point I want to make a step back and redo some of the original patches 
without using cpusets. At least for now while we do not have clear agreement 
on how cpuset integration should look like it seems to make sense to simply 
extend existing interfaces. For the irqs specifically I'm just thinking of 
adding /proc/irq/default_smp_affinity. I'll send some patches later this week.

Max