Mailing List Archive

Reverting per-cpuset "system" (IRQ affinity) patch (was: Fix cpuset sched_relax_domain_level control file)
pj wrote:
> What's the easiest way to get from where we are now, to a world
> without that patch?

Would it help, Andrew, if I proposed a patch that went into your latest
mmtom stack, right after the three patches:

origin.patch
linux-next.patch
Paul Menage's latest "Fix cpuset sched_relax_domain_level control file"

that reverted the cpuset "system" patch (this being a patch that added
a per-cpuset file called "system", which could be used to do things
such as help manage the assignment of IRQs to CPUs.)

I suspect that some of Ingo, Max Krasnyanskiy, or Peter Zijlstra will
not be happy with my doing this, but I'm pretty sure that the "system"
patch needs more work before we have agreement on the API. I really
don't want to add the API of that current patch "as is" to the kernel.

I've added several of the people who were part of the preceding threads
on this discussion to the CC list.

I'm cooking up such a patch now -- I've gotten to the point that it
applies and builds; now I am about to see how badly it breaks the
remaining 426 patches in the mmtom stack.

--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.940.382.4214
--
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/
Re: Reverting per-cpuset "system" (IRQ affinity) patch (was: Fix cpuset sched_relax_domain_level control file) [ In reply to ]
On Tue, 6 May 2008 22:38:59 -0500 Paul Jackson <pj@sgi.com> wrote:

> pj wrote:
> > What's the easiest way to get from where we are now, to a world
> > without that patch?
>
> Would it help, Andrew, if I proposed a patch that went into your latest
> mmtom stack, right after the three patches:
>
> origin.patch
> linux-next.patch
> Paul Menage's latest "Fix cpuset sched_relax_domain_level control file"
>
> that reverted the cpuset "system" patch (this being a patch that added
> a per-cpuset file called "system", which could be used to do things
> such as help manage the assignment of IRQs to CPUs.)
>
> I suspect that some of Ingo, Max Krasnyanskiy, or Peter Zijlstra will
> not be happy with my doing this, but I'm pretty sure that the "system"
> patch needs more work before we have agreement on the API. I really
> don't want to add the API of that current patch "as is" to the kernel.
>
> I've added several of the people who were part of the preceding threads
> on this discussion to the CC list.
>
> I'm cooking up such a patch now -- I've gotten to the point that it
> applies and builds; now I am about to see how badly it breaks the
> remaining 426 patches in the mmtom stack.

Don't worry about it. I sorted out things locally and I expect that
Stephen will be able to as well. Hopefully Ingo will toss the whole patch
series so we can take another look at it all.


--
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/
Re: Reverting per-cpuset "system" (IRQ affinity) patch (was: Fix cpuset sched_relax_domain_level control file) [ In reply to ]
Andrew wrote:
> Don't worry about it. I sorted out things locally and I expect that
> Stephen will be able to as well.

Ok ...

I hesitate more than I should some times to NAQ patches,
but the more I think about this one, the less willing I
am to have a per-cpuset file called "system".

I'm not sure what "sorted out" means ... I'll wait and see.

Thanks, Andrew.

Sorry, Max, Peter and Ingo ... we really had not arrived at
agreement on this one.

--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.940.382.4214
--
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/
Re: Reverting per-cpuset "system" (IRQ affinity) patch (was: Fix cpuset sched_relax_domain_level control file) [ In reply to ]
On Tue, 2008-05-06 at 22:52 -0500, Paul Jackson wrote:
> Andrew wrote:
> > Don't worry about it. I sorted out things locally and I expect that
> > Stephen will be able to as well.
>
> Ok ...
>
> I hesitate more than I should some times to NAQ patches,
> but the more I think about this one, the less willing I
> am to have a per-cpuset file called "system".
>
> I'm not sure what "sorted out" means ... I'll wait and see.
>
> Thanks, Andrew.
>
> Sorry, Max, Peter and Ingo ... we really had not arrived at
> agreement on this one.

No problem, I've been meaning to redo this whole series but somehow
stuff got in the way and I never got around to it :-/


--
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/
Re: Reverting per-cpuset "system" (IRQ affinity) patch [ In reply to ]
Peter Zijlstra wrote:
> On Tue, 2008-05-06 at 22:52 -0500, Paul Jackson wrote:
>> Andrew wrote:
>>> Don't worry about it. I sorted out things locally and I expect that
>>> Stephen will be able to as well.
>> Ok ...
>>
>> I hesitate more than I should some times to NAQ patches,
>> but the more I think about this one, the less willing I
>> am to have a per-cpuset file called "system".
>>
>> I'm not sure what "sorted out" means ... I'll wait and see.
>>
>> Thanks, Andrew.
>>
>> Sorry, Max, Peter and Ingo ... we really had not arrived at
>> agreement on this one.
>
> No problem, I've been meaning to redo this whole series but somehow
> stuff got in the way and I never got around to it :-/

I'm actually totally surprised that it got in. Ingo applied Peter's initial
patch to his sched-devel tree but then ignored follow up patches with fixes
and stuff from me (I'm assuming that was because we started discussion
alternative options).
Anyway, my vote goes for reverting these series.

Max
--
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/
Re: Reverting per-cpuset "system" (IRQ affinity) patch [ In reply to ]
* Max Krasnyansky <maxk@qualcomm.com> wrote:

> > No problem, I've been meaning to redo this whole series but somehow
> > stuff got in the way and I never got around to it :-/
>
> I'm actually totally surprised that it got in. Ingo applied Peter's
> initial patch to his sched-devel tree but then ignored follow up
> patches with fixes and stuff from me (I'm assuming that was because we
> started discussion alternative options).

yes, there's been a lot of back and forth.

Paul/Peter/Max, what's the current agreed-upon approach 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.

> Anyway, my vote goes for reverting these series.

none of this is upstream yet (nor is any of this even near to being
ready for upstream), so there's nothing to revert.

Ingo
--
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/
Re: Reverting per-cpuset "system" (IRQ affinity) patch [ In reply to ]
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.

--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.940.382.4214
--
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/
Re: Reverting per-cpuset "system" (IRQ affinity) patch [ In reply to ]
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







--
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/