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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100912234442.GA22778@Krystal>
Date:	Sun, 12 Sep 2010 19:44:42 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	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

* Mathieu Desnoyers (mathieu.desnoyers@...icios.com) wrote:
> * Ingo Molnar (mingo@...e.hu) wrote:
[...]
> > I.e. please re-phrase your series as: "what else does it give us beyond 
> > tuning down the minimum granularity to 33% of its current value?"
> 
> That's indeed the nice way to phrase the question. So the added value of my
> approach is that I don't change the granularity when there are 3 or less tasks
> running on the system. So, with Peter's approach, I expect that the system
> throughput will be lower in this scenario, but my approach should keep it at
> pretty much the same values as the vanilla kernel.
> 
> But you are right, I should put some performance measurements too. Let me do a
> few test runs (I plan to use tbench) and come back with the measurements with
> nr_running <= 3 for both Peter's approach and mine.

It turns out that tbench is rather more latency-sensitive than
throughput-sensitive :

tbench 1, on UP 2.0GHz

* Mainline 2.6.35.2 kernel
Throughput 184.875 MB/sec  1 clients  1 procs  max_latency=12.158 ms

* With my patches (dynamic granularity)
Throughput 185.99 MB/sec  1 clients  1 procs  max_latency=14.683 ms

* With Peter's approach (smaller granularity)
Throughput 188.784 MB/sec  1 clients  1 procs  max_latency=8.061 ms

So as we can see, my approach has a behavior that's much closer to mainline, but
the tbench workload seems to favor smaller granularity here. I'm open to ideas
about benchmarks that would test throughput without being so sensitive to
latency.

Thanks,

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/