| From | Sent On | Attachments |
|---|---|---|
| Alexander Motin | Feb 5, 2012 11:04 pm | |
| David Xu | Feb 5, 2012 11:59 pm | |
| Gary Jennejohn | Feb 6, 2012 2:08 am | |
| Alexander Best | Feb 6, 2012 8:01 am | |
| Alexander Motin | Feb 6, 2012 8:28 am | |
| Tijl Coosemans | Feb 6, 2012 9:37 am | |
| Alexander Motin | Feb 6, 2012 9:54 am | |
| Florian Smeets | Feb 6, 2012 11:07 am | |
| Alexander Best | Feb 6, 2012 11:10 am | |
| Alexander Motin | Feb 6, 2012 11:18 am | |
| Julian Elischer | Feb 6, 2012 10:10 pm | |
| Ivan Voras | Feb 8, 2012 3:06 am | |
| Andriy Gapon | Feb 11, 2012 5:34 am | |
| Alexander Motin | Feb 11, 2012 6:21 am | |
| Konstantin Belousov | Feb 11, 2012 7:35 am | |
| Andriy Gapon | Feb 11, 2012 9:04 am | |
| Alexander Motin | Feb 13, 2012 11:56 am | |
| Jeff Roberson | Feb 13, 2012 12:23 pm | |
| Alexander Motin | Feb 13, 2012 12:54 pm | |
| Jeff Roberson | Feb 13, 2012 1:39 pm | |
| Alexander Motin | Feb 13, 2012 2:38 pm | |
| Alexander Motin | Feb 15, 2012 11:46 am | |
| Jeff Roberson | Feb 15, 2012 11:54 am | |
| Alexander Motin | Feb 15, 2012 12:06 pm | |
| Alexander Motin | Feb 15, 2012 8:41 pm | |
| Alexander Motin | Feb 16, 2012 12:48 am | |
| Alexander Motin | Feb 16, 2012 2:58 am | |
| Florian Smeets | Feb 16, 2012 1:28 pm | |
| Alexander Motin | Feb 17, 2012 8:29 am | |
| Arnaud Lacombe | Feb 17, 2012 8:52 am | |
| Alexander Motin | Feb 17, 2012 9:02 am | |
| George Mitchell | Feb 26, 2012 4:32 pm | |
| George Mitchell | Feb 26, 2012 4:37 pm | |
| Olivier Smedts | Feb 27, 2012 2:34 am | |
| George Mitchell | Feb 27, 2012 3:23 am | |
| Olivier Smedts | Feb 27, 2012 3:27 am | |
| Andriy Gapon | Feb 27, 2012 4:41 am | |
| George Mitchell | Feb 27, 2012 3:54 pm | |
| Adrian Chadd | Mar 2, 2012 3:05 pm | |
| George Mitchell | Mar 2, 2012 4:14 pm | |
| Adrian Chadd | Mar 2, 2012 7:24 pm | |
| Alexander Motin | Mar 2, 2012 11:40 pm | |
| Ivan Klymenko | Mar 3, 2012 12:18 am | |
| Adrian Chadd | Mar 3, 2012 12:59 am | |
| Alexander Motin | Mar 3, 2012 1:12 am | |
| Alexander Motin | Mar 3, 2012 4:53 am | |
| Ivan Klymenko | Mar 3, 2012 7:25 am | |
| Alexander Motin | Mar 3, 2012 8:30 am | |
| Mario Lobo | Mar 3, 2012 8:56 am | |
| Alexander Motin | Mar 3, 2012 9:56 am | |
| Ivan Klymenko | Mar 3, 2012 11:15 am | |
| Arnaud Lacombe | Apr 5, 2012 11:11 am | |
| Alexander Motin | Apr 5, 2012 11:45 am | |
| Attilio Rao | Apr 6, 2012 7:12 am | |
| Alexander Motin | Apr 6, 2012 7:26 am | |
| Attilio Rao | Apr 6, 2012 7:30 am | |
| Alexander Motin | Apr 6, 2012 7:40 am | |
| Alexander Motin | Apr 9, 2012 12:57 pm | |
| Arnaud Lacombe | Apr 10, 2012 9:57 am | |
| Alexander Motin | Apr 10, 2012 10:18 am | |
| Alexander Motin | Apr 10, 2012 10:53 am | |
| Arnaud Lacombe | Apr 10, 2012 11:45 am | |
| Alexander Motin | Apr 10, 2012 12:13 pm | |
| Mike Meyer | Apr 10, 2012 1:04 pm | |
| Arnaud Lacombe | Apr 10, 2012 1:50 pm | |
| Mike Meyer | Apr 10, 2012 2:19 pm | |
| Adrian Chadd | Apr 11, 2012 3:19 pm |
| Subject: | Re: [RFT][patch] Scheduling for HTT and not only | |
|---|---|---|
| From: | Alexander Motin (ma...@FreeBSD.org) | |
| Date: | Apr 10, 2012 12:13:19 pm | |
| List: | org.freebsd.freebsd-hackers | |
On 04/10/12 21:46, Arnaud Lacombe wrote:
On Tue, Apr 10, 2012 at 1:53 PM, Alexander Motin<ma...@freebsd.org> wrote:
On 04/10/12 20:18, Alexander Motin wrote:
On 04/10/12 19:58, Arnaud Lacombe wrote:
2012/4/9 Alexander Motin<ma...@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@test:/test/hackbench# ./hackbench 30 process 1000 Running with 30*40 (== 1200) tasks. Time: 9.568
mav@test:/test/hackbench# sysctl kern.sched.interact=0 kern.sched.interact: 30 -> 0 mav@test:/test/hackbench# ./hackbench 30 process 1000 Running with 30*40 (== 1200) tasks. Time: 5.163
mav@test:/test/hackbench# sysctl kern.sched.interact=100 kern.sched.interact: 0 -> 100 mav@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.
I don't really care on this point, I'm only testing default values, or more precisely, whatever developers though default values would be good.
Btw, you are testing 3 differents configuration. Different results are expected. What worries me more is the rather the huge instability on the *same* configuration, say on a pipe/thread/70 groups/600 iterations run, where results range from 2.7s[0] to 7.4s, or a socket/thread/20 groups/1400 iterations run, where results range from 2.4s to 4.5s.
Due to reason I've pointed in my first message this test is _extremely_ sensitive to context switch interval. The more aggressive scheduler switches threads, the smaller will be pipe latency, but the smaller will be also bandwidth. During test run scheduler all the time recalculates interactivity index for each thread, trying to balance between latency and switching overhead. With hundreds of threads running simultaneously and interfering with each other it is quite unpredictable process.
-- Alexander Motin
_______________________________________________ free...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "free...@freebsd.org"





