[RFT][patch] Scheduling for HTT and not only

Alexander Motin mav at FreeBSD.org
Tue Apr 10 17:54:05 UTC 2012


On 04/10/12 20:18, Alexander Motin wrote:
> On 04/10/12 19:58, Arnaud Lacombe wrote:
>> 2012/4/9 Alexander Motin<mav at freebsd.org>:
>>> [...]
>>>
>>> I have strong feeling that while this test may be interesting for
>>> profiling,
>>> it's own results in first place depend not from how fast scheduler
>>> is, but
>>> from the pipes capacity and other alike things. Can somebody hint me
>>> what
>>> except pipe capacity and context switch to unblocked receiver prevents
>>> sender from sending all data in batch and then receiver from
>>> receiving them
>>> all in batch? If different OSes have different policies there, I think
>>> results could be incomparable.
>>>
>> Let me disagree on your conclusion. If OS A does a task in X seconds,
>> and OS B does the same task in Y seconds, if Y> X, then OS B is just
>> not performing good enough. Internal implementation's difference for
>> the task can not be waived as an excuse for result's comparability.
>
> Sure, numbers are always numbers, but the question is what are they
> showing? Understanding of the test results is even more important for
> purely synthetic tests like this. Especially when one test run gives 25
> seconds, while another gives 50. This test is not completely clear to me
> and that is what I've told.

Small illustration to my point. Simple scheduler tuning affects thread 
preemption policy and changes this test results in three times:

mav at test:/test/hackbench# ./hackbench 30 process 1000
Running with 30*40 (== 1200) tasks.
Time: 9.568

mav at test:/test/hackbench# sysctl kern.sched.interact=0
kern.sched.interact: 30 -> 0
mav at test:/test/hackbench# ./hackbench 30 process 1000
Running with 30*40 (== 1200) tasks.
Time: 5.163

mav at test:/test/hackbench# sysctl kern.sched.interact=100
kern.sched.interact: 0 -> 100
mav at test:/test/hackbench# ./hackbench 30 process 1000
Running with 30*40 (== 1200) tasks.
Time: 3.190

I think it affects balance between pipe latency and bandwidth, while 
test measures only the last. It is clear that conclusion from these 
numbers depends on what do we want to have.

-- 
Alexander Motin


More information about the freebsd-hackers mailing list