linux-kernel - Re: [git pull request] scheduler updates

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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.LFD.0.999.0708241105410.25853@woody.linux-foundation.org>
Date:	Fri, 24 Aug 2007 11:09:56 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [git pull request] scheduler updates

On Fri, 24 Aug 2007, Ingo Molnar wrote:
> 
> Then there's also a change/tweak that increases the default granularity: 
> it's still well below human perception so should not be noticeable, but 
> servers win a bit from less preemption of CPU-bound tasks. (this is also 
> the first step towards eliminating HZ from the granularity default 
> calculation.)

Your explanation makes NO sense.

It doesn't eliminate HZ at all. It's still there, and it's still totally 
bogus.

Please just *remove* that thing. It has no possible value! You claim that 
the preemption granularity is in "ns", and that it defaults to "3 msec", 
but it does no such thing at all, even with your patch. It does:

	unsigned int sysctl_sched_granularity __read_mostly = 3000000000ULL/HZ;

which is just total and utter CRAP!

Why the hell can't you just make the code sane and do what the comment 
*says* it does, and just admit that HZ has nothing what-so-ever to do with 
that thing, and then you do

	unsigned int sysctl_sched_granularity __read_mostly = 3000000ULL;

and be done with it. Instead of this *insane* expectation that HZ is 
always 1000, and any other value means that you want bigger granularity, 
which is not true and makes no sense.

So dammit, stop writing these totally bogus "explanations". If you have a 
reason why the granularity needs to be HZ-dependent, *document* that 
reason, and make the code actually match the comment, instead of 
continually documenting things that SIMPLY ARE NOT TRUE.

Ingo, I'm not going to pull this kind of antics and crap.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/