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: <alpine.LFD.0.999.0707281417201.3442@woody.linux-foundation.org>
Date:	Sat, 28 Jul 2007 14:33:47 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jan Engelhardt <jengelh@...putergmbh.de>
cc:	Kasper Sandberg <lkml@...anurb.dk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	CK Mailinglist <ck@....kolivas.org>
Subject: Re: Linus 2.6.23-rc1



On Sat, 28 Jul 2007, Linus Torvalds wrote:
> 
> Yes, it's what "/proc/sys/kernel/sched_granularity_ns" is supposed to 
> tweak, but maybe there's some misfeature there, or maybe the default is 
> just bad for games, or whatever.
> 
> Ingo: that sysctl_sched_granularity initialization doesn't make sense. You 
> talk about it being in units of nanoseconds, but then you do
> 
> 	2000000000ULL/HZ
> 
> which is nonsensical.

Btw, people who actually have 3D games installed (I have exactly one: 
ppracer, and I can't really say that I care about how it feels), if you 
don't have CONFIG_HZ=1000, this really is worth testing.

I think Ingo probably ran with CONFIG_NO_HZ and HZ_1000, but the default 
timer tick is actually 250Hz, which makes all the default scheduler values 
come out four times bigger than they are documented/supposed to be.

On SMP, that scheduler granularity then gets doubled once more if you have 
two CPU's, so rather than 2ms by default, it ends up being 16ns (and the 
time slices themselves end up being bigger than that). 

So doing some testing with a simple

	echo 2000000 > /proc/sys/kernel/sched_granularity_ns
	echo 1000000 > /proc/sys/kernel/sched_batch_wakeup_granularity_ns
	echo 8000000 > /proc/sys/kernel/sched_runtime_limit_ns

might be worth doing (and if you vary numbers to see if it matters, 
please do let people know!)

		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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ