linux-kernel - Re: [ck] Re: Linus 2.6.23-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <200707282003.45142.jos@mijnkamer.nl>
Date:	Sat, 28 Jul 2007 20:03:41 +0200
From:	jos poortvliet <jos@...nkamer.nl>
To:	ck@....kolivas.org
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Michael Chang <thenewme91@...il.com>,
	Kasper Sandberg <lkml@...anurb.dk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [ck] Re: Linus 2.6.23-rc1

Op Saturday 28 July 2007, schreef Linus Torvalds:
> On Sat, 28 Jul 2007, Michael Chang wrote:
> > I do recall there is one issue on which Con wouldn't budge -- anything
> > that involved boosting certain kinds of processes in the kernel.
>
> I did that myself, so that's a non-issue.
>
> No. The complaints were about the CK scheduler not being as responsive
> under load as even the _old_ scheduler was. I don't know why people ignore
> this fact. It was a long thread back in March or April, and I'm pretty
> sure the CK mailing list was cc'd.

Of course it wasn't. The speed of tasks slows proportionally with the amount 
of system usage. That's the whole point, and CFS can't fix that either, can 
it?

> Sure, most people don't actually have load-averages above ten etc, but
> it's important to do those well _too_.
>
> 			Linus

<sarcasm>
http://osnews.com/permalink.php?news_id=18350&comment_id=259044

Now I wonder. Apparently, one person complaining about SD was reason to keep 
it out http://osnews.com/permalink.php?news_id=18350&comment_id=258997

Will this first post stop CFS from entering the kernel?
</sarcasm>

Now I'll try to be a bit more constructive. I hope your benevolent 
dictatorship allows self reflection.

Sure, the difference in behaviour (not in code) between SD and CFS is small, 
and for me it doesn't matter. I'm fine with CFS in the kernel, it's a huge 
improvement over the previous one. But why, while there was a seemingly good 
alternative, did THAT one stay in that long? And this argument goes for more 
code 'out there', btw.

 Some things get into the kernel, other don't. Some get in too soon, others 
too late. Sure. But shouldn't we try to improve this process, instead of 
saying 'it is what it is, get over it'?

 For me, that's the purpose of this whole discussion. We're losing valuable 
code and contributors, yet at the same time code which isn't mature yet 
enters the kernel. Acknowledging there is a problem is the first step in 
solving it.

 Of course, I don't have answers - but I do feel strongly that you think there 
is no issue. Is there, or isn't there? And if there is, what do you plan to 
do about it?

Your influence on the behaviour of the people around you, your 'lieutenants', 
is huge. Larger than you might think. And in many cases, ppl following 
someone behave more extreme. That's a big reason why the LKML isn't very 
polite nor inviting (mind you, I don't think that's necessarily a bad thing, 
that's up to you to decide).

You might want to think about ways to improve the whole process. Again, I'm no 
Linus, it's your call. And you can make a big difference, I'm sure.

Greetings,

Jos

Download attachment "signature.asc " of type "application/pgp-signature" (190 bytes)