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

From: Mathieu Desnoyers
Date: Sun Sep 12 2010 - 19:45:22 EST


* Mathieu Desnoyers (mathieu.desnoyers@xxxxxxxxxxxx) wrote:
> * Ingo Molnar (mingo@xxxxxxx) 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/