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

Mathieu Desnoyers
2010-09-12T23:44:49Z

* Mathieu Desnoyers (mathieu.desnoyers@efficios.com) wrote:
> * Ingo Molnar (mingo@elte.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.