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: <20100912203712.GD32327@Krystal>
Date:	Sun, 12 Sep 2010 16:37:12 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	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>,
	Mike Galbraith <efault@....de>
Subject: Re: [RFC patch 1/2] sched: dynamically adapt granularity with
	nr_running

* Peter Zijlstra (peterz@...radead.org) wrote:
> On Sat, 2010-09-11 at 15:57 -0400, Mathieu Desnoyers wrote:
> > The interesting part is in the range from 4 to 8 tasks. I diminish the scheduler
> > granularity as the number of tasks increases rather than increasing latency.
> > This leads to more scheduler preemptions than usual, but only in the 4-8 running
> > tasks range. 
> 
> I really don't get it.. that's exactly what it does from the 1..3 range
> too, if you want to extend that, simply set a lower min_gran, it will
> update nr_latency and you get it from 1..(latency/min_gran) range.
> 
> And you didn't touch sched_proc_update_handler(), which recomputes
> sched_nr_latency when you change sched_latency or sched_min_gran.
> 
> So the current stuff is:
> 
>   period := max(latency, min_gran * nr_running)
> 
> or, conversely:
> 
>   gran := max(min_gran, latency / nr_running)
> 
> Which seems to be exactly what you want, no? Its doing that!
> 
> Except that in the one place we used 'gran' directly we avoided the
> division and used the minimal value: min_gran in all cases, which is a
> trade-of favouring latency.

The whole point of my patch is not to have to do this latency vs performance
tradeoff for low number of running threads. With your approach, lowering the
granularity even when there are few threads running will very likely hurt
performance, no ?

Mathieu


-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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/