linux-kernel - Re: sched: fix/optimise some issues

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: <1311266608.29152.170.camel@twins>
Date:	Thu, 21 Jul 2011 18:43:28 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Stephan Bärwolf 
	<stephan.baerwolf@...ilmenau.de>
Cc:	linux-kernel@...r.kernel.org, Nikhil Rao <ncrao@...gle.com>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: sched: fix/optimise some issues

(you seem to have lost CC's, restored them)

On Thu, 2011-07-21 at 18:36 +0200, Stephan Bärwolf wrote:
> > How horrid is the current vruntime situation?
> This is a point, which needs further discussion/observation.
> 
> When for example NICE0_LOAD is increased by 6 Bit (and I think
> "c8b281161dfa4bb5d5be63fb036ce19347b88c63" did it by 10bits
> on x86_64) the maximum timeslice (I am not quite sure if it was on
> HZ=1000) with a PRE kernel will be around 2**38.
> Adding this every ms (lets say 1024 times per sec) to min_vruntime
> might cause overflows too fast (after 2**(63-38-10)sec = 2**15sec ~ 9h).

9h should be just fine, and I think we can get down to minutes without
really breaking much. As long as the wrap period is at least twice the
duration of the period needed to service all tasks.

So what we want is the wrap to be > 2*nr_running*sched_min_granularity.

> Long story short: on x86_64 an unsigned long (timeslice) could be
> as large as the whole u64 for min_vruntime and this is dangerous.

> Of course limiting the maximum timeslice in "calc_delta_mine()" would
> help, too - but without the comfort using the whole x86_64 capabilties.
> (and mostly therefore finer priority-resolutions) 

It should be limited by HZ, that is I don't think there is a situation
where we can get a bigger real-time delta than 1s/HZ.
--
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/