Re: sched: fix/optimise some issues

[Peter Zijlstra]

(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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/