Paul Jackson wrote:
quoted text
> Max wrote:
>> So I expect two ACKs for isolcpu= removal from both of you, in bold please :)
> 
> Not from me, anyway.
> 
> I've seen enough replies (thanks!) from users of isolcpus=
> to be quite certain that we should not just remove it outright.
We've seen exactly two replies with usage examples. Dimitri's case is legit
but can be handled much better (as in it not only avoids timers, but any other
kernel work) with cpu hotplug and cpusets. Ingo's case is bogus because it
does not actually do what he needs. There is a much better way to do exactly
what he needs which involves only cpu hotplug and has nothing to do with the
scheduler and such.

quoted text
> I will NAQ such proposals.
> 
> And until, and unless, someone comes up with a persuasive answer
> to Nick's question:
> 
>> is there a real reason _to_ remove it?
> 
> I'll probably NAQ proposals to deprecate it as well.
> 
> Max ... I think one place where you and I disagree is on whether
> it is a good idea to have multiple ways to accomplish the same
> thing.
Not really. I thought that the two ways that we have are conflicting.
I just looked at the partition_sched_domains() code again and realized that
there is no conflict (cpusets settings override isolcpus=). I was wrong on that.
So I guess there are no reasons to nuke other than
	"oh, but it's was a hack" :)

quoted text
> As Ingo Oeser pointed out:
>> The initrd is from the distribution. I have no sane way to change it
> 
> Even if you do find a way that seems sane to you, that's not the point,
> in my view.  Further, given the constraints on producing product that
> will fit in with multiple distributions, I doubt that the alternatives
> you suggest to Info Oeser would work well for him anyway.
> A key reason that Linux has succeeded is that it actively seeks to work
> for a variety of people, purposes and products.  One operating system is
> now a strong player in  the embedded market, the real time market, and
> the High Performance Computing market, as well as being an important
> player in a variety of other markets.  That's a rather stunning success.
> 
> If you went to your local grocery store with your (if you have one)
> young child, and found that they had no Lucky Charms breakfast cereal
> (your childs favorite) you would not be pleased if the store manager
> tried to sell you Fruit Loops instead ... just as much sugar and food
> coloring.
> 
> If we have features that seem to duplicate functionality, in a
> different way, and that aren't causing us substantial grief to
> maintain, and that aren't significantly hurting our performance or
> robustness or security or seriously getting in the way of further
> development, then we usually leave those features in.
> 
> Please understand, Max, that for every kernel hacker working in this
> corner of the Linux kernel, there are a hundred or a thousand users
> depending on what we do, and who will have to adapt to any incompatible
> changes we make.  If we save ourselves an hour by removing "unnecessary"
> features, we can cost a hundred others each some time adapting to this
> change.  A few of those others may get hit for substantial effort, if
> the change catches them unawares at the wrong time and place.
> 
> As good citizens of the universe, we should seek to optimize the
> aggregate effort we spend to obtain a particular level of quality and
> functionality.
> 
> Saving yourself an hour while you cost a hundred others ten minutes
> each is not a net gain.  Sometimes this means not enforcing a "one way,
> and one way only, to do any given task." I wouldn't go as far as Perl
> does in this regard, but we do run a more polyglot product than say
> Python.
> 
> Try thinking a little more like a WalMart product manager than a
> Ferrari designer.  If it is currently selling to our customers, and if
> we can fit it into our supply and distribution chain, and if we can
> continue to make an adequate profit per foot of shelf space, then
> continue to buy it, stock it, ship it, and sell it.

Ingo's case is a bad example. If you reread his use case more carefully you'll
see that he was not actually getting what he expected out of the boot param in
question.

btw Impressive write up. I do like to think of myself as a Ferrari designer,
actually these days I'm more into http://www.teslamotors.com/ rather than
Ferrari :).
So I agree in general of course. As I mentioned my reasoning was 1) I thought
it conflicts with cpusets and 2) it's considered a hack by the scheduler folks
and is not supported (ie my attempts to extend it were rejected). Given that
there is a better mechanism available it seemed to make sense to nuke it.
Peter Z and Ingo M were of the similar opinion, so it seemed.

Anyway, I do not mind us keeping isolcpus= boot option even though use cases
mentioned so far as not very convincing.

Max



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