* Scheduler Situation
@ 2007-08-03 12:07 T. J. Brumfield
2007-08-03 12:31 ` Alistair John Strachan
` (4 more replies)
0 siblings, 5 replies; 21+ messages in thread
From: T. J. Brumfield @ 2007-08-03 12:07 UTC (permalink / raw)
To: linux-kernel
First off, I am an avid reader of the LKML but I'm not a developer.
Admittedly I am a piss-poor C developer who likes to poke around the
code, play with patches and attempt to learn, but in reality at best I
pretend I understand it, and I don't really. I fully defer to the
technical knowledge of far greater minds on this list. Even having a
basic understanding of C and looking at the code, I still don't
understand basic kernel operations like memory management or CPU
scheduling well enough to see in code what works best.
What I can say, is that someone who has had years of project
management experience, it is painfully obvious here that there are
events here in personal issues which should be easy to spot and
rectify.
I, like many people, had been using Con's patches for years and were
greatly pleased by them. I've experimented with a variety of kernel
flavor and patches, often woefully trying to amass my own collection
of custom patches and often breaking things while trying to integrate
too many patches at once that don't patch nicely with one another.
And when I've had questions, I often read through Con's mailing list
archives from his site.
It would appear he spent 4 years working on his patch-set, primarily
based around his version of a scheduler. And in reading the LKML it
seems that aspects of his patch-set he pushed for mainline inclusion.
He was shot down saying that his ideas were flat-out wrong, and still
he worked for years to improve his work. He answered questions, fixed
bugs, and made himself very available.
It may very well be that CFS is a better scheduler than SD. Ingo is a
very respected coder, and from even Con's mouth it seems that CFS is
pretty simple in its execution. Ingo seems to suggest that since he
posted his code so quickly after he wrote it, that he didn't do
anything wrong.
Linus, a man I greatly admire and respect, especially for his
blunt/terse statements, also seems to suggest that no one has wronged
Con here. However in insisting that the decision was based on Con's
inability to support his code, I can fully understand why Con would
leave kernel development permanently.
The simple truth is that Con poured years into a project despite being
rebuffed and told he was wrong. The moment that people change their
minds and realize that his concepts have merit, no one apologizes for
all the past criticism. Ingo did very much credit Con for
inspiration, but I can't see how this decision was anything but
political. Linus said it himself, that he trusts Ingo to stand behind
the code, and he didn't trust Con to do the same.
I am reticent to accuse anyone of dishonesty, but that statement just
doesn't seem to add up. And even if that is the way Linus truly felt,
it doesn't seem fair given how well Con had supported his code and his
users. Regardless for a man who claims to not make political
decisions on code, that is exactly how he operated here. He chose the
person over the code. From his own mouth, it seemed he remains very
put off by earlier comments from the "Con camp" that perhaps there
should be separation between the server and desktop kernels.
And while Linus is no-doubt correct that such a separation should not
occur, I never really saw Con push for such a thing. I know I don't
fully understand the code, but it does seem to make sense to an idiot
like me however that with all the other kernel options to customize
your build for your needs, it isn't beyond reason to go with a
plugsched type solution. The kernel is already immensely modular, no
doubt the most modular piece of code on the planet.
It works amazingly well in small embedded devices to large
multi-processor servers across multiple architectures and processor
types. The reason I'm posting on an issue I'm sure that many people
are already sick of, is that I'm sure many people would like to see
two things happen.
1 - Can someone please explain why the kernel can be modular in every
other aspect, including offering a choice of IO schedulers, but not
kernel schedulers?
2 - Can't we all agree that this was poorly handled? Politics should
not affect code, and we are all adults. People should accept
rejection of patches, and what not. At the same time, if I were Con
I'd be extremely hurt, and many people have echoed this very
sentiment. I think a project of this size that depends so much on a
large community for testing, contributions, etc. can't afford to
alienate people in this fashion. Con may never come back to kernel
land. That's unfortunate, but this needs to be addressed. I'm sure a
whole lot of people would feel better if they knew this kind of
treatment is not likely to happen again, and ideally I think Con
should get an apology.
If I'm a developer who sits outside the usual circle of contributers,
and I have an idea for a big change in the kernel, how likely am I to
devote a bunch of time if I have the impression that my work will be
shot down, rewritten by another person, and lastly I will be
personally attacked rather than thanked for my contributions?
I'm really hoping that we can take moment to display some
consideration for the feelings of others here, not to babysit or
placate, but rather to set a precedent for such an important project
on how contributers will be treated.
-- T. J. Brumfield
"In the beginning the Universe was created. This has made a lot of
people very angry and been widely regarded as a bad move."
--Douglas Adams
"Nihilism makes me smile."
--Christopher Quic
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Scheduler Situation
2007-08-03 12:07 Scheduler Situation T. J. Brumfield
@ 2007-08-03 12:31 ` Alistair John Strachan
2007-08-03 12:52 ` Oleksandr Natalenko
` (3 subsequent siblings)
4 siblings, 0 replies; 21+ messages in thread
From: Alistair John Strachan @ 2007-08-03 12:31 UTC (permalink / raw)
To: T. J. Brumfield; +Cc: linux-kernel
The real question is WHY do people keep writing essays about topics that have
_already_ been exhaustively explored in other threads? If you want a better
understanding of the situation, read the archives, DON'T post another
duplicate message about the same scheduler parade.
Unless you've got some constructive input that goes further than asking the
same questions that have already been asked and answered multiple times
before, please just do not pollute this list.
It's becoming so repetitive this almost sounds like a 419.
--
Cheers,
Alistair.
137/1 Warrender Park Road, Edinburgh, UK.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Scheduler Situation
2007-08-03 12:07 Scheduler Situation T. J. Brumfield
2007-08-03 12:31 ` Alistair John Strachan
@ 2007-08-03 12:52 ` Oleksandr Natalenko
[not found] ` <192840a00708030616g22d9dd16o95b2620bfe3347a8@mail.gmail.com>
2007-08-03 13:00 ` debian developer
` (2 subsequent siblings)
4 siblings, 1 reply; 21+ messages in thread
From: Oleksandr Natalenko @ 2007-08-03 12:52 UTC (permalink / raw)
To: linux-kernel
T. J. Brumfield <enderandrew <at> gmail.com> writes:
> 1 - Can someone please explain why the kernel can be modular in every
> other aspect, including offering a choice of IO schedulers, but not
> kernel schedulers?
IMHO, Linus has a grudge against Con, but I can't understand, why. Con has
written nice code, I use it even now, I'm glad to have nice high-interactive
system on desktop. But "a grudge" is not an argument for Linus, it's better not
to make a decision by himself, but to let the community to decide, what is
better - CFS or SD.
Question is not only in CFS vs SD, but in -ck patchset. Linus must remember
that he has lost nice code and nice maintainer, and it's not a right decision.
Linux is a public OS, so let people decide themselves, but not Linus himself.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Scheduler Situation
2007-08-03 12:07 Scheduler Situation T. J. Brumfield
2007-08-03 12:31 ` Alistair John Strachan
2007-08-03 12:52 ` Oleksandr Natalenko
@ 2007-08-03 13:00 ` debian developer
2007-08-03 15:28 ` about modularization Ingo Molnar
2007-08-03 13:19 ` Ingo Molnar
[not found] ` <200708031354.15485.alistair@devzero.co.uk>
4 siblings, 1 reply; 21+ messages in thread
From: debian developer @ 2007-08-03 13:00 UTC (permalink / raw)
To: T. J. Brumfield; +Cc: linux-kernel
On 8/3/07, T. J. Brumfield <enderandrew@gmail.com> wrote:
> First off, I am an avid reader of the LKML but I'm not a developer.
> Admittedly I am a piss-poor C developer who likes to poke around the
> code, play with patches and attempt to learn, but in reality at best I
> pretend I understand it, and I don't really. I fully defer to the
> technical knowledge of far greater minds on this list. Even having a
> basic understanding of C and looking at the code, I still don't
> understand basic kernel operations like memory management or CPU
> scheduling well enough to see in code what works best.
>
> What I can say, is that someone who has had years of project
> management experience, it is painfully obvious here that there are
> events here in personal issues which should be easy to spot and
> rectify.
>
> I, like many people, had been using Con's patches for years and were
> greatly pleased by them. I've experimented with a variety of kernel
> flavor and patches, often woefully trying to amass my own collection
> of custom patches and often breaking things while trying to integrate
> too many patches at once that don't patch nicely with one another.
> And when I've had questions, I often read through Con's mailing list
> archives from his site.
>
> It would appear he spent 4 years working on his patch-set, primarily
> based around his version of a scheduler. And in reading the LKML it
> seems that aspects of his patch-set he pushed for mainline inclusion.
> He was shot down saying that his ideas were flat-out wrong, and still
> he worked for years to improve his work. He answered questions, fixed
> bugs, and made himself very available.
>
> It may very well be that CFS is a better scheduler than SD. Ingo is a
> very respected coder, and from even Con's mouth it seems that CFS is
> pretty simple in its execution. Ingo seems to suggest that since he
> posted his code so quickly after he wrote it, that he didn't do
> anything wrong.
>
> Linus, a man I greatly admire and respect, especially for his
> blunt/terse statements, also seems to suggest that no one has wronged
> Con here. However in insisting that the decision was based on Con's
> inability to support his code, I can fully understand why Con would
> leave kernel development permanently.
>
> The simple truth is that Con poured years into a project despite being
> rebuffed and told he was wrong. The moment that people change their
> minds and realize that his concepts have merit, no one apologizes for
> all the past criticism. Ingo did very much credit Con for
> inspiration, but I can't see how this decision was anything but
> political. Linus said it himself, that he trusts Ingo to stand behind
> the code, and he didn't trust Con to do the same.
>
> I am reticent to accuse anyone of dishonesty, but that statement just
> doesn't seem to add up. And even if that is the way Linus truly felt,
> it doesn't seem fair given how well Con had supported his code and his
> users. Regardless for a man who claims to not make political
> decisions on code, that is exactly how he operated here. He chose the
> person over the code. From his own mouth, it seemed he remains very
> put off by earlier comments from the "Con camp" that perhaps there
> should be separation between the server and desktop kernels.
>
> And while Linus is no-doubt correct that such a separation should not
> occur, I never really saw Con push for such a thing. I know I don't
> fully understand the code, but it does seem to make sense to an idiot
> like me however that with all the other kernel options to customize
> your build for your needs, it isn't beyond reason to go with a
> plugsched type solution. The kernel is already immensely modular, no
> doubt the most modular piece of code on the planet.
>
> It works amazingly well in small embedded devices to large
> multi-processor servers across multiple architectures and processor
> types. The reason I'm posting on an issue I'm sure that many people
> are already sick of, is that I'm sure many people would like to see
> two things happen.
>
> 1 - Can someone please explain why the kernel can be modular in every
> other aspect, including offering a choice of IO schedulers, but not
> kernel schedulers?
Good question. has been answered in other threads. Linus does'nt like
having separate kernel schedulers.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: about modularization
2007-08-03 12:07 Scheduler Situation T. J. Brumfield
` (2 preceding siblings ...)
2007-08-03 13:00 ` debian developer
@ 2007-08-03 13:19 ` Ingo Molnar
[not found] ` <cdc89fe60708030651s54b5f0e0j938450632cf621c5@mail.gmail.com>
` (2 more replies)
[not found] ` <200708031354.15485.alistair@devzero.co.uk>
4 siblings, 3 replies; 21+ messages in thread
From: Ingo Molnar @ 2007-08-03 13:19 UTC (permalink / raw)
To: T. J. Brumfield; +Cc: linux-kernel
* T. J. Brumfield <enderandrew@gmail.com> wrote:
> 1 - Can someone please explain why the kernel can be modular in every
> other aspect, including offering a choice of IO schedulers, but not
> kernel schedulers?
that's a fundamental misconception. If you boot into a distro kernel on
a typical PC, about half of the kernel code that the box runs in any
moment will be in modules, half of it is in the "kernel core". For
example, on a random laptop:
$ echo `lsmod | cut -c1-30 | cut -d' ' -f2-` | sed 's/Size //' |
sed 's/ /+/g' | bc
2513784
i.e. 2.5 MB of modules. The core kernel's size:
$ dmesg | grep 'kernel code'
Memory: 2053212k/2087808k available (2185k kernel code, 33240k reserved, 1174k data, 244k init, 1170304k highmem)
2.1 MB of kernel core code. (of course the total body of "possible
drivers" is 10 times larger than that of the core kernel - but the
fundamental 'variety' is not.)
most of the modules are for stuff where there is a significant physical
difference between the components they support. Drivers for different
pieces of hardware. Filesystem drivers for different on-disk physical
layouts. Network protocol drivers for different on-wire formats. The
sanest technological decision there is clearly to modularize.
And note that often it's not even about choice there: the user's system
has a particular piece of hardware, to which there is usually one
primary driver. The user does not have any real 'choice' over the
modularization here, it's largely a technological act to make the
kernel's footprint smaller.
But the kernel core, which does not depend as much on the physical
properties of the stuff it supports (it depends on the physics of the
machine of course, but those rules are mostly shared between all
machines of that architecture), and is fundamentally influenced by the
syscall API (which is not modular either) and by our OS design
decisions, has much less reason to be modularized.
The core kernel was always non-modular, and it depends on the technical
details whether we want to or _have to_ modularize something so that it
becomes modular to the user too. For example we dont have 'competing',
modular versions of the IPv4 stack. Neither of the VFS. Nor of timers,
futexes, nor of locking code or of the CPU scheduler. But we can switch
out any of those implementations from the core kernel, and did so
numerous times in the past and will do so in the future.
CPU schedulers are as core kernel code as it gets - you cannot even boot
without having a CPU scheduler. IO schedulers, although similar in name,
are quite different beasts from CPU schedulers, and they are somewhere
between the core kernel and drivers. They are not 'physical drivers' (an
IO scheduler can drive any disk), nor are they fully 'core kernel code'
in the sense of a kernel not even being able to boot without them. Also,
disks are physically different from CPUs, in a way which works _against_
the user-modularization of CPU schedulers. (there are also many other
differences which have been pointed out in the past)
In any case, the IO subsystem maintainers decided to modularize IO
schedulers, and that's their decision. One of the authors of the IO
scheduler code said it on lkml recently that while modularization of IO
scheduler had advantages too, in retrospect he wishes they would not
have made IO schedulers modular and now that decision cannot be undone.
So even that much different situation was far from a clear decision, and
some negative effects can be felt today too, in form of having two
primary IO schedulers but not having one IO scheduler that works well in
all cases. For CPU schedulers the circumstances point away away from
user-selectable modularization even stronger.
Ingo
^ permalink raw reply [flat|nested] 21+ messages in thread
* Scheduler Situation
[not found] ` <192840a00708030616g22d9dd16o95b2620bfe3347a8@mail.gmail.com>
@ 2007-08-03 13:27 ` Андрій Мішковський
2007-08-03 13:45 ` Alistair John Strachan
0 siblings, 1 reply; 21+ messages in thread
From: Андрій Мішковський @ 2007-08-03 13:27 UTC (permalink / raw)
To: linux-kernel
Bad things may happen if Linus gives a right of making decision to
other people (a big group of people). ;)
As you said, Linux is a public OS, so Con's code never will be lost.
That's the base of open source - people come and go, but the code
stays. :)
2007/8/3, Oleksandr Natalenko <pfactum@gmail.com>:
> Question is not only in CFS vs SD, but in -ck patchset. Linus must remember
> that he has lost nice code and nice maintainer, and it's not a right decision.
> Linux is a public OS, so let people decide themselves, but not Linus himself.
>
> -
> 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/
>
This is re-post of personal mail to Olexander.
--
Wbr, Andriy Mishkovskyy.
He's got a heart of a little child, and he keeps it in a jar on his desk.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Scheduler Situation
2007-08-03 13:27 ` Андрій Мішковський
@ 2007-08-03 13:45 ` Alistair John Strachan
0 siblings, 0 replies; 21+ messages in thread
From: Alistair John Strachan @ 2007-08-03 13:45 UTC (permalink / raw)
To: Андрій
Мішковський
Cc: linux-kernel
On Friday 03 August 2007 14:27:30 Андрій Мішковський wrote:
> Bad things may happen if Linus gives a right of making decision to
> other people (a big group of people). ;)
> As you said, Linux is a public OS, so Con's code never will be lost.
> That's the base of open source - people come and go, but the code
> stays. :)
Unfortunately Con undermined this by leaving all kernel development. So unless
somebody else is sufficiently motivated to constructively improve SD (and I
think we all hope they will, competition is good), it will probably die.
--
Cheers,
Alistair.
137/1 Warrender Park Road, Edinburgh, UK.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Fwd: about modularization
[not found] ` <cdc89fe60708030651s54b5f0e0j938450632cf621c5@mail.gmail.com>
@ 2007-08-03 13:52 ` T. J. Brumfield
2007-08-03 15:02 ` Ingo Molnar
2007-08-03 15:13 ` Ingo Molnar
0 siblings, 2 replies; 21+ messages in thread
From: T. J. Brumfield @ 2007-08-03 13:52 UTC (permalink / raw)
To: linux-kernel
On 8/3/07, Ingo Molnar <mingo@elte.hu> wrote:
> snip...
Except that a working prototype of plugsched exists and functions
exactly as advertised. I understand that modules can be loaded and
unloaded, where as other aspects of the core kernel can't just
load/unload as the kernel is running, but the cpu scheduler could be
selected at boot via a command line, or as a kconfig option when
compiling like the io scheduler.
And while the io team may feel that it would be best to have one
scheduler that worked well under all circumstances, often this can't
simply be the case. Benchmarks over the years seem to suggest that
different schedulers work different for different situations. In that
regard, choice does seem to be nice.
CFS is apparently better in its simplicity, however others are
reporting that SD still provides benefits for 3D gaming. Perhaps
there are instances where even more schedulers like nicksched might be
the most appropriate solution.
-- T. J.
"In the beginning the Universe was created. This has made a lot of
people very angry and been widely regarded as a bad move."
--Douglas Adams
"Nihilism makes me smile."
--Christopher Quick
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Scheduler Situation
[not found] ` <200708031540.29687.alistair@devzero.co.uk>
@ 2007-08-03 14:51 ` T. J. Brumfield
2007-08-03 15:05 ` Alistair John Strachan
0 siblings, 1 reply; 21+ messages in thread
From: T. J. Brumfield @ 2007-08-03 14:51 UTC (permalink / raw)
To: Alistair John Strachan; +Cc: linux-kernel
> I'm not going to argue with this point because I think this is exactly what
> Linus meant. He wanted a scheduler that worked. And he knew it wouldn't work
> immediately after merging it. So he had to go with the person that he trusted
> the most to make it work, quickly. And this was Ingo. That might not be
> a "purely" technical reason, but I suspect it's a correct one.
You're demonstrating a lack of reason here. In the same post Linus
said repeatedly that he feels Con isn't someone he wanted to work with
because he felt Con refused to listen to bug reports and was
argumentative. And never once did Linus say that CFS would work out
of the box. He said it was new code that needs plenty of testing. In
fact he said that is why he was against plugsched, because if people
ran different schedulers, then CFS would get less testing. You're
just putting motives in Linus' mouth that weren't there to begin with.
He picked a person over a piece of code, and his reasoning for picking
a person was flawed. By Linus' own statements we should choose a
person who has demonstrated they could support scheduler code for
years. Con did exactly that, where as Ingo said he never imagined
he'd write a scheduler. Linus made up some bogus accusations about
Con and that isn't cool. I'm not sure why anyone would argue this
point. Attacking volunteers in a volunteer project is just bad form,
and my entire purpose of ever writing this list that already gets far
too much traffic is to voice my displeasure in exactly this matter.
I've always respected Linus despite his many public disputes.
Generally he argues his point gruffly, but he has reason and logic on
his side. Here he has a personal grudge, and the community is weaker
now because of it.
> Who cares? You can't say either Linus or Ingo are any worse in this regard, so
> it's irrelevant when discussing why SD wasn't chosen. This is just as
> political as anything negative that Linus said.
I imagine if it was your pet project, and you were trampled on in this
manner, you'd care. And I don't like seeing people abused like this.
I also don't care to see a project I care about weakened due to petty
drama and politics. I had hoped the Linux community was above this.
Your lack of compassion in the matter however is duly noted. We have
polar views and aren't going to agree.
I'll leave it at that.
-- T. J. Brumfield
"In the beginning the Universe was created. This has made a lot of
people very angry and been widely regarded as a bad move."
--Douglas Adams
"Nihilism makes me smile."
--Christopher Quick
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: about modularization
2007-08-03 13:52 ` Fwd: " T. J. Brumfield
@ 2007-08-03 15:02 ` Ingo Molnar
2007-08-03 15:13 ` Ingo Molnar
1 sibling, 0 replies; 21+ messages in thread
From: Ingo Molnar @ 2007-08-03 15:02 UTC (permalink / raw)
To: T. J. Brumfield; +Cc: linux-kernel
* T. J. Brumfield <enderandrew@gmail.com> wrote:
> On 8/3/07, Ingo Molnar <mingo@elte.hu> wrote:
> > snip...
>
> Except that a working prototype of plugsched exists and functions
> exactly as advertised. [...]
a prototype for dynamic syscalls exists too. A prototype for pluggable
network IPv4 stacks exists too. A working implementation existed for
STREAMS too. Existence of a patch still does not make any of them a good
idea for the core kernel.
[ If existence of a patch was the only criterium for upstream merging
then we'd have a much poorer quality Linux kernel today. Odds are that
in that case you would not even know what 'Linux' means, it would
still be an obscure, niche hacker's toy somewhere on the 'net ;-) ]
> [...] I understand that modules can be loaded and unloaded, where as
> other aspects of the core kernel can't just load/unload as the kernel
> is running, but the cpu scheduler could be selected at boot via a
> command line, or as a kconfig option when compiling like the io
> scheduler.
i replied to that in my previous mail:
But the kernel core, which does not depend as much on the physical
properties of the stuff it supports (it depends on the physics of the
machine of course, but those rules are mostly shared between all
machines of that architecture), and is fundamentally influenced by
the syscall API (which is not modular either) and by our OS design
decisions, has much less reason to be modularized.
But to put it in different words:
_certain core kernel code should not be pluggable_
and whether it should or should not be pluggable is an entirely
technical decision, up to the maintainers of that code.
> And while the io team may feel that it would be best to have one
> scheduler that worked well under all circumstances, often this can't
> simply be the case. [...]
you skipped the bit where i pointed it out how different CPU scheduling
is from IO scheduling. Plus now you are arguing against the opinion of
an IO maintainer too? :-)
Ingo
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Scheduler Situation
2007-08-03 14:51 ` Scheduler Situation T. J. Brumfield
@ 2007-08-03 15:05 ` Alistair John Strachan
0 siblings, 0 replies; 21+ messages in thread
From: Alistair John Strachan @ 2007-08-03 15:05 UTC (permalink / raw)
To: T. J. Brumfield; +Cc: linux-kernel
On Friday 03 August 2007 15:51:59 T. J. Brumfield wrote:
> > I'm not going to argue with this point because I think this is exactly
> > what Linus meant. He wanted a scheduler that worked. And he knew it
> > wouldn't work immediately after merging it. So he had to go with the
> > person that he trusted the most to make it work, quickly. And this was
> > Ingo. That might not be a "purely" technical reason, but I suspect it's a
> > correct one.
>
> You're demonstrating a lack of reason here. In the same post Linus
> said repeatedly that he feels Con isn't someone he wanted to work with
> because he felt Con refused to listen to bug reports and was
> argumentative.
Which is refuted only by your personal experience, not by any facts that have
yet been posted.
> And never once did Linus say that CFS would work out
> of the box. He said it was new code that needs plenty of testing. In
> fact he said that is why he was against plugsched, because if people
> ran different schedulers, then CFS would get less testing. You're
> just putting motives in Linus' mouth that weren't there to begin with.
This has gone too far. I said NO such thing. I repeatedly stated in previous
emails that the decision was based on code that, _although not perfect on
submission_ could most rapidly be made to work. You have just twisted what
I've said here to contradict that. Please read ALL of my emails, instead of
selectively attacking only what you disagree with.
( I also don't appreciate being copied back onto LKML, after a long email
diatribe (which you selectively did not copy). It's just bad netiquette. )
> > Who cares? You can't say either Linus or Ingo are any worse in this
> > regard, so it's irrelevant when discussing why SD wasn't chosen. This is
> > just as political as anything negative that Linus said.
>
> I imagine if it was your pet project, and you were trampled on in this
> manner, you'd care. And I don't like seeing people abused like this.
I certainly wouldn't expect my code to be taken. If somebody else's was taken,
I would accept that I was powerless to make them do otherwise. That's what
benevolent dictatorships are all about and what somebody familiar with Linux
development should expect.
The best way to deal with "injustices" is to constructively move past them.
Con decided to leave the community, and that's another option. I just think
everybody's lost out, himself included.
> I also don't care to see a project I care about weakened due to petty
> drama and politics. I had hoped the Linux community was above this.
> Your lack of compassion in the matter however is duly noted. We have
> polar views and aren't going to agree.
LKML isn't _normally_ a place for compassion, but for code, and I'm pretty
sure that if there was less compassion we'd have fewer flamewars and less of
the petty politics that you are complaining so loudly about.
Either you can convince Linus to change his mind, or you can't. Complaining
about it will achieve nothing other than to increase the noise to signal on
LKML.
--
Cheers,
Alistair.
137/1 Warrender Park Road, Edinburgh, UK.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: about modularization
2007-08-03 13:52 ` Fwd: " T. J. Brumfield
2007-08-03 15:02 ` Ingo Molnar
@ 2007-08-03 15:13 ` Ingo Molnar
1 sibling, 0 replies; 21+ messages in thread
From: Ingo Molnar @ 2007-08-03 15:13 UTC (permalink / raw)
To: T. J. Brumfield; +Cc: linux-kernel
* T. J. Brumfield <enderandrew@gmail.com> wrote:
> CFS is apparently better in its simplicity, however others are
> reporting that SD still provides benefits for 3D gaming. [...]
even for 3D gaming the opposite of what you say seems to be the case:
http://people.redhat.com/mingo/misc/cfs-sd-ut2004-perf.jpg
http://people.redhat.com/mingo/misc/cfs-vs-sd-wine-quake.jpg
( more such measurements were done and reported, i stopped doing
graphs after the first two. )
but in any case, the main "target" of CFS was not even SD (although it
is certainly desirable to handle any load at least as well as SD) but
the _mainline_ scheduler. SD was the primary selection of a relatively
small subset of existing Linux users, and SD had known (and intentional)
tradeoffs over the mainline scheduler in certain areas. CFS tried to do
zero tradeoffs over the existing scheduler, to not introduce regressions
to the many users who found the existing scheduler just good enough.
That's been a success so far, at the moment there's no open CFS
"interactivity regression" relative to the 2.6.22 mainline scheduler.
Ingo
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: about modularization
2007-08-03 13:00 ` debian developer
@ 2007-08-03 15:28 ` Ingo Molnar
0 siblings, 0 replies; 21+ messages in thread
From: Ingo Molnar @ 2007-08-03 15:28 UTC (permalink / raw)
To: debian developer; +Cc: T. J. Brumfield, linux-kernel
* debian developer <debiandev@gmail.com> wrote:
> > 1 - Can someone please explain why the kernel can be modular in
> > every other aspect, including offering a choice of IO schedulers,
> > but not kernel schedulers?
>
> Good question. has been answered in other threads. Linus does'nt like
> having separate kernel schedulers.
not just Linus, but neither me nor Nick Piggin, nor a ton of other
kernel hackers agree with that idea, for numerous technical reasons,
as it has been discussed to death already ;-)
and the last but not least point, although they might sound pretty
similar, there is quite a bit of difference between "IO schedulers" and
"CPU schedulers", just like there is quite a bit of difference between
"Paris Hilton" and "The Hilton, Paris" =B-)
Ingo
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: about modularization
2007-08-03 13:19 ` Ingo Molnar
[not found] ` <cdc89fe60708030651s54b5f0e0j938450632cf621c5@mail.gmail.com>
@ 2007-08-03 17:47 ` Rene Herman
2007-08-03 18:59 ` Ingo Molnar
2007-09-01 22:02 ` Oleg Verych
2 siblings, 1 reply; 21+ messages in thread
From: Rene Herman @ 2007-08-03 17:47 UTC (permalink / raw)
To: Ingo Molnar; +Cc: T. J. Brumfield, linux-kernel
On 08/03/2007 03:19 PM, Ingo Molnar wrote:
> One of the authors of the IO scheduler code said it on lkml recently that
> while modularization of IO scheduler had advantages too, in retrospect he
> wishes they would not have made IO schedulers modular and now that
> decision cannot be undone.
Just as a matter of interest -- why can't it? (a pointer to a list archive
if you have one, or a name so I can look for it myself if you don't, will do
as answer).
Rene.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: about modularization
2007-08-03 17:47 ` Rene Herman
@ 2007-08-03 18:59 ` Ingo Molnar
0 siblings, 0 replies; 21+ messages in thread
From: Ingo Molnar @ 2007-08-03 18:59 UTC (permalink / raw)
To: Rene Herman; +Cc: linux-kernel
* Rene Herman <rene.herman@gmail.com> wrote:
> On 08/03/2007 03:19 PM, Ingo Molnar wrote:
>
> > One of the authors of the IO scheduler code said it on lkml recently
> > that while modularization of IO scheduler had advantages too, in
> > retrospect he wishes they would not have made IO schedulers modular
> > and now that decision cannot be undone.
>
> Just as a matter of interest -- why can't it? (a pointer to a list
> archive if you have one, or a name so I can look for it myself if you
> don't, will do as answer).
some apps depend on AS, some on CFQ, and once you expose something to
users it's _very_ hard to remove it, even if the technical arguments are
strong.
http://lists.openwall.net/linux-kernel/2007/04/16/23
Ingo
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: about modularization
2007-08-03 13:19 ` Ingo Molnar
[not found] ` <cdc89fe60708030651s54b5f0e0j938450632cf621c5@mail.gmail.com>
2007-08-03 17:47 ` Rene Herman
@ 2007-09-01 22:02 ` Oleg Verych
2 siblings, 0 replies; 21+ messages in thread
From: Oleg Verych @ 2007-09-01 22:02 UTC (permalink / raw)
To: Ingo Molnar; +Cc: T. J. Brumfield, linux-kernel
* Date: Fri, 3 Aug 2007 15:19:00 +0200
* Received-SPF: softfail (mx3: transitioning domain of elte.hu does not designate 157.181.1.14 as permitted sender) client-ip=157.181.1.14; envelope-from=mingo@elte.hu; helo=elvis.elte.hu;
> If you boot into a distro kernel on
> a typical PC, about half of the kernel code that the box runs in any
> moment will be in modules, half of it is in the "kernel core". For
> example, on a random laptop:
That was your laptop and distro.
> $ echo `lsmod | cut -c1-30 | cut -d' ' -f2-` | sed 's/Size //' |
> sed 's/ /+/g' | bc
> 2513784
>
> i.e. 2.5 MB of modules. The core kernel's size:
>
> $ dmesg | grep 'kernel code'
> Memory: 2053212k/2087808k available (2185k kernel code, 33240k reserved, 1174k data, 244k init, 1170304k highmem)
>
> 2.1 MB of kernel core code. (of course the total body of "possible
> drivers" is 10 times larger than that of the core kernel - but the
> fundamental 'variety' is not.)
Just for reference here's my 2+ years old Asus A4K, kernel is form
Debian Etch:
deen:/tmp# uname -a
Linux deen 2.6.18-4-amd64 #1 SMP Mon Mar 26 11:36:53 CEST 2007 x86_64 x86_64
deen:/tmp# lsmod | (read a; while read a b c; do S=$((b+${S=0})); done; echo $S)
1583684
deen:/tmp# lsmod | grep xfs
xfs 485192 3
deen:/tmp# dmesg | grep kernel\ code
Memory: 506676k/523520k available (1930k kernel code, 16456k reserved, 868k data, 176k init)
Apart from diff in hardware and implied designing/coding skills, decision
was made
* after one "wrong" response plus illness from Con,
* brave core-duo by Ingo and Tomas, who made some bunch of students to test
scheduler and reported success to Linus.
I don't know why, after all that variety of things (mostly drivers, but
recent *fd also) there's such big resistance to anything that's useful
and used by ordinary people. A star sickness, pride? If yes, that's just
ridiculous, but who cares.
____
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: about modularization
2007-08-06 23:35 ` Rene Herman
@ 2007-08-06 23:45 ` Rene Herman
0 siblings, 0 replies; 21+ messages in thread
From: Rene Herman @ 2007-08-06 23:45 UTC (permalink / raw)
To: Mitchell Erblich; +Cc: linux-kernel, Ingo Molnar, T. J. Brumfield
On 08/07/2007 01:35 AM, Rene Herman wrote:
> On 08/06/2007 11:48 PM, Mitchell Erblich wrote:
>
>> Of the uni-processor systems currently that can run Linux, I would not
>> doubt if 99.9999% percent are uni-cores.
>
> s/can// and I would. s/uni-processor// additionally and I'd assure you
> it's untrue. s/uni-cores/non-smt uni-cores/ and I'd do the same.
(no, that's obviously wrong given embedded volumes, but as stated below,
embedded is fine running non-generic, !CONFIG_SMP kernels).
Rene.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: about modularization
2007-08-06 21:48 Mitchell Erblich
@ 2007-08-06 23:35 ` Rene Herman
2007-08-06 23:45 ` Rene Herman
0 siblings, 1 reply; 21+ messages in thread
From: Rene Herman @ 2007-08-06 23:35 UTC (permalink / raw)
To: Mitchell Erblich; +Cc: linux-kernel, Ingo Molnar, T. J. Brumfield
On 08/06/2007 11:48 PM, Mitchell Erblich wrote:
> Of the uni-processor systems currently that can run Linux, I would not
> doubt if 99.9999% percent are uni-cores.
s/can// and I would. s/uni-processor// additionally and I'd assure you it's
untrue. s/uni-cores/non-smt uni-cores/ and I'd do the same.
> It will be probably 3-5 years minimum before the multi-core processors
> will have any decent percentage of systems.
Which is also approximately the same timeframe in which one might consider
currently developped kernels obsolete for deployment by the way...
> And I am not suggesting not supporting them. I am only suggesting is wrt
> the schedular, bring the system up with a default schedular, and then
> load additional functionality based on the hardware/software requirements
> of the system.
But why? First, look at the number of #ifdef CONFIG_SMP in the scheduler
code -- the Linux kernel already has seperate UP/SMP schedulers selected
through CONFIG_SMP. Embedded can certainly use its own !CONFIG_SMP kernels,
for Linux servers SMP is the norm today and for the desktop/home, SMP
probably already _also_ is the norm today, what with multi-core and HT
(which needs different things than real SMP does, but is also certainly not
UP). And if it isn't, it will be tomorrow and stay that way for the
forseeable future.
[ snip ]
> IMO, if their is a fault (because of heat, etc) the user would rather
> bring up the system in a degraded mode. Same reason applies to... boot
> -s..
To what? I don't understand this comment. You are optimizing for the case of
a dead CPU? Why would the user care if he'd be running the most optimal
scheduler for the situation when his box is limping along anyway?
Rene.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: about modularization
@ 2007-08-06 21:48 Mitchell Erblich
2007-08-06 23:35 ` Rene Herman
0 siblings, 1 reply; 21+ messages in thread
From: Mitchell Erblich @ 2007-08-06 21:48 UTC (permalink / raw)
To: Rene Herman; +Cc: linux-kernel, Ingo Molnar, "T. J. Brumfield"
Rene,
Of the uni-processor systems currently that can run Linux, I would not
doubt if 99.9999% percent are uni-cores. It will be probably
3-5 years minimum before the multi-core processors will have any
decent percentage of systems.
And I am not suggesting not supporting them. I am only suggesting
is wrt the schedular, bring the system up with a default schedular,
and then load additional functionality based on the hardware/software
requirements of the system.
Thus, the fallout MIGHT be a uni-processor CFS that would not migrate
tasks between multiple CPUs and as additional processors are brought
online, migration could be enabled, and gang type scheduling, whatever
could be then used.
IMO, if their is a fault (because of heat, etc) the user would rather
bring
up the system in a degraded mode. Same reason applies to...
boot -s..
Mitchell Erblich
------------------------------
Rene Herman wrote:
>
> On 08/06/2007 10:20 PM, Mitchell Erblich wrote:
>
> > Thus, a hybrid schedular approach could be taken
> > that would default to a single uni-processor schedular
>
> What a brilliant idea in a world where buying a non multi core CPU is
> getting to be only somewhat easier than a non SMT one...
>
> Rene.
> -
> 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/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: about modularization
2007-08-06 20:20 about modularization Mitchell Erblich
@ 2007-08-06 20:50 ` Rene Herman
0 siblings, 0 replies; 21+ messages in thread
From: Rene Herman @ 2007-08-06 20:50 UTC (permalink / raw)
To: Mitchell Erblich; +Cc: linux-kernel, Ingo Molnar, T. J. Brumfield
On 08/06/2007 10:20 PM, Mitchell Erblich wrote:
> Thus, a hybrid schedular approach could be taken
> that would default to a single uni-processor schedular
What a brilliant idea in a world where buying a non multi core CPU is
getting to be only somewhat easier than a non SMT one...
Rene.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: about modularization
@ 2007-08-06 20:20 Mitchell Erblich
2007-08-06 20:50 ` Rene Herman
0 siblings, 1 reply; 21+ messages in thread
From: Mitchell Erblich @ 2007-08-06 20:20 UTC (permalink / raw)
To: linux-kernel; +Cc: Ingo Molnar, "T. J. Brumfield"
Ingo Molnar and group,
If we just concentrate on CPU schedulars...
IMO, POSIX requirements almost guarantee
the support for modularization. The different
task scheds allow a set of task class specific
funcs to be generated. The question is whether
those modular schedulars will ALWAYS consume
kernel footprint space?
With the arg of modularization is really targeted
to optional hardware and decreases the kernel
footprint size. Then here is a arg to support only 1
default schedular and take the rest of the sched
code and modularize that..
IMO, ONLY some envs REQUIRE RT
sched and some envs REQUIRE MP
(multi-core and multi-processor) scheduling.
I question whether the core kernel needs
this support.
.
This additional capability could be removed
from the growing kernel footprint and
additional schedulars could be kept in the src
code base with increasingly minimal effort if full
modularization support were added.
Thus, a hybrid schedular approach could be taken
that would default to a single uni-processor schedular
(ex: CFS) and the other schedulars could be
modularized.
Mitchell Erblich
------------------------
Ingo Molnar wrote:
>
> * T. J. Brumfield <enderandrew@gmail.com> wrote:
>
> > 1 - Can someone please explain why the kernel can be modular in every
> > other aspect, including offering a choice of IO schedulers, but not
> > kernel schedulers?
>
> that's a fundamental misconception. If you boot into a distro kernel on
> a typical PC, about half of the kernel code that the box runs in any
> moment will be in modules, half of it is in the "kernel core". For
> example, on a random laptop:
>
> $ echo `lsmod | cut -c1-30 | cut -d' ' -f2-` | sed 's/Size //' |
> sed 's/ /+/g' | bc
> 2513784
>
> i.e. 2.5 MB of modules. The core kernel's size:
>
> $ dmesg | grep 'kernel code'
> Memory: 2053212k/2087808k available (2185k kernel code, 33240k reserved,
1174k data, 244k init, 1170304k highmem)
>
> 2.1 MB of kernel core code. (of course the total body of "possible
> drivers" is 10 times larger than that of the core kernel - but the
> fundamental 'variety' is not.)
>
> most of the modules are for stuff where there is a significant physical
> difference between the components they support. Drivers for different
> pieces of hardware. Filesystem drivers for different on-disk physical
> layouts. Network protocol drivers for different on-wire formats. The
> sanest technological decision there is clearly to modularize.
>
> And note that often it's not even about choice there: the user's system
> has a particular piece of hardware, to which there is usually one
> primary driver. The user does not have any real 'choice' over the
> modularization here, it's largely a technological act to make the
> kernel's footprint smaller.
>
> But the kernel core, which does not depend as much on the physical
> properties of the stuff it supports (it depends on the physics of the
> machine of course, but those rules are mostly shared between all
> machines of that architecture), and is fundamentally influenced by the
> syscall API (which is not modular either) and by our OS design
> decisions, has much less reason to be modularized.
>
> The core kernel was always non-modular, and it depends on the technical
> details whether we want to or _have to_ modularize something so that it
> becomes modular to the user too. For example we dont have 'competing',
> modular versions of the IPv4 stack. Neither of the VFS. Nor of timers,
> futexes, nor of locking code or of the CPU scheduler. But we can switch
> out any of those implementations from the core kernel, and did so
> numerous times in the past and will do so in the future.
>
> CPU schedulers are as core kernel code as it gets - you cannot even boot
> without having a CPU scheduler. IO schedulers, although similar in name,
> are quite different beasts from CPU schedulers, and they are somewhere
> between the core kernel and drivers. They are not 'physical drivers' (an
> IO scheduler can drive any disk), nor are they fully 'core kernel code'
> in the sense of a kernel not even being able to boot without them. Also,
> disks are physically different from CPUs, in a way which works _against_
> the user-modularization of CPU schedulers. (there are also many other
> differences which have been pointed out in the past)
>
> In any case, the IO subsystem maintainers decided to modularize IO
> schedulers, and that's their decision. One of the authors of the IO
> scheduler code said it on lkml recently that while modularization of IO
> scheduler had advantages too, in retrospect he wishes they would not
> have made IO schedulers modular and now that decision cannot be undone.
> So even that much different situation was far from a clear decision, and
> some negative effects can be felt today too, in form of having two
> primary IO schedulers but not having one IO scheduler that works well in
> all cases. For CPU schedulers the circumstances point away away from
> user-selectable modularization even stronger.
>
> 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/
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2007-09-01 21:47 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-08-03 12:07 Scheduler Situation T. J. Brumfield
2007-08-03 12:31 ` Alistair John Strachan
2007-08-03 12:52 ` Oleksandr Natalenko
[not found] ` <192840a00708030616g22d9dd16o95b2620bfe3347a8@mail.gmail.com>
2007-08-03 13:27 ` Андрій Мішковський
2007-08-03 13:45 ` Alistair John Strachan
2007-08-03 13:00 ` debian developer
2007-08-03 15:28 ` about modularization Ingo Molnar
2007-08-03 13:19 ` Ingo Molnar
[not found] ` <cdc89fe60708030651s54b5f0e0j938450632cf621c5@mail.gmail.com>
2007-08-03 13:52 ` Fwd: " T. J. Brumfield
2007-08-03 15:02 ` Ingo Molnar
2007-08-03 15:13 ` Ingo Molnar
2007-08-03 17:47 ` Rene Herman
2007-08-03 18:59 ` Ingo Molnar
2007-09-01 22:02 ` Oleg Verych
[not found] ` <200708031354.15485.alistair@devzero.co.uk>
[not found] ` <cdc89fe60708030712q391de609o3999a870ea7cbcbd@mail.gmail.com>
[not found] ` <200708031540.29687.alistair@devzero.co.uk>
2007-08-03 14:51 ` Scheduler Situation T. J. Brumfield
2007-08-03 15:05 ` Alistair John Strachan
2007-08-06 20:20 about modularization Mitchell Erblich
2007-08-06 20:50 ` Rene Herman
2007-08-06 21:48 Mitchell Erblich
2007-08-06 23:35 ` Rene Herman
2007-08-06 23:45 ` Rene Herman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.