Re: [RFC patch 1/2] sched: dynamically adapt granularity withnr_running

[Mike Galbraith]

On Mon, 2010-09-13 at 09:56 -0400, Mathieu Desnoyers wrote:
> * Peter Zijlstra (peterz@xxxxxxxxxxxxx) wrote:

> > One option is to simply get rid of that stuff in check_preempt_tick()
> > and instead do a wakeup-preempt check on the leftmost task instead.
> > 
> > The code as it stands today does that delta_exec < min_gran check to
> > ensure current gets some runtime before doing that second preemption
> > check, which compares vruntime with a wall-time measure.
> > 
> > Making that gran more complex doesn't really buy us much because for a
> > system with different weights in the gran and slice lengths don't match
> > up anyway.
> 
> So I bet this last sentence is about the example of a system with many nice 19
> processes I told you about on IRC. Yes, this one is a bummer, as we would not
> like to count them as running threads at all.

Tick doesn't help much with nice 19, tick is much larger than slice, so
barring wakeup preemption, nice 19 tasks should _slam_ right when the
tick finally arrives.

> >  	/*
> > -	 * Ensure that a task that missed wakeup preemption by a
> > -	 * narrow margin doesn't have to wait for a full slice.
> > -	 * This also mitigates buddy induced latencies under load.
> > +	 * The current task ran long enough, ensure it doesn't get
> > +	 * re-elected due to buddy favours.
> >  	 */
> > -	if (!sched_feat(WAKEUP_PREEMPT))
> > -		return;
> > -
> > -	if (delta_exec < sysctl_sched_min_granularity)
> > -		return;
> 
> Well, the reason why this test is here seems to be that we don't want to trigger
> "resched_task" more often than needed...

Yeah.  Heavily niced tasks would usually be booted before we got this
far because of small slices, just making sure to not evict some first
class citizen _too_ soon while trying to reduce latency a bit.  If a
heavily niced task slips through, oh darn, but it did before too.

	-Mike

--
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/