linux-kernel - Re: [RFC patch 1/2] sched: dynamically adapt granularity with nr

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: <1284389078.10436.40.camel@marge.simson.net>
Date:	Mon, 13 Sep 2010 16:44:38 +0200
From:	Mike Galbraith <efault@....de>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tony Lindgren <tony@...mide.com>
Subject: Re: [RFC patch 1/2] sched: dynamically adapt granularity with
 nr_running

On Mon, 2010-09-13 at 09:56 -0400, Mathieu Desnoyers wrote:
> * Peter Zijlstra (peterz@...radead.org) 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/