BFS vs. mainline scheduler benchmarks and measurements
in [Kernel]
|
Prev: [PATCH 1/1] AGP: amd64, fix pci reference leaks
Next: [PATCH 2/3] viafb: remove unused structure member
From: Michael Buesch on 7 Sep 2009 11:20 Here's a very simple test setup on an embedded singlecore bcm47xx machine (WL500GPv2) It uses iperf for performance testing. The iperf server is run on the embedded device. The device is so slow that the iperf test is completely CPU bound. The network connection is a 100MBit on the device connected via patch cable to a 1000MBit machine. The kernel is openwrt-2.6.30.5. Here are the results: Mainline CFS scheduler: mb(a)homer:~$ iperf -c 192.168.1.1 ------------------------------------------------------------ Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.99 port 35793 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 27.4 MBytes 23.0 Mbits/sec mb(a)homer:~$ iperf -c 192.168.1.1 ------------------------------------------------------------ Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.99 port 35794 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 27.3 MBytes 22.9 Mbits/sec mb(a)homer:~$ iperf -c 192.168.1.1 ------------------------------------------------------------ Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.99 port 56147 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 27.3 MBytes 22.9 Mbits/sec BFS scheduler: mb(a)homer:~$ iperf -c 192.168.1.1 ------------------------------------------------------------ Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.99 port 52489 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 38.2 MBytes 32.0 Mbits/sec mb(a)homer:~$ iperf -c 192.168.1.1 ------------------------------------------------------------ Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.99 port 52490 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 38.1 MBytes 31.9 Mbits/sec mb(a)homer:~$ iperf -c 192.168.1.1 ------------------------------------------------------------ Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.99 port 52491 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 38.1 MBytes 31.9 Mbits/sec -- Greetings, Michael. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Frans Pop on 7 Sep 2009 11:30 On Monday 07 September 2009, Arjan van de Ven wrote: > 4 cores, 8 threads. Which is basically the standard desktop cpu going > forward... (4 cores already is today, 8 threads is that any day now) Despite that I'm personally more interested in what I have available here *now*. And that's various UP Pentium systems, one dual core Pentium D and Core Duo. I've been running BFS on my laptop today while doing CPU intensive jobs (not disk intensive), and I must say that BFS does seem very responsive. OTOH, I've also noticed some surprising things, such as processors staying on lower frequencies while doing CPU-intensive work. I feels like I have less of the mouse cursor and typing freezes I'm used to with CFS, even when I'm *not* doing anything special. I've been blaming those on still running with ordered mode ext3, but now I'm starting to wonder. I'll try to do more structured testing, comparisons and measurements later. At the very least it's nice to have something to compare _with_. Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Frans Pop on 7 Sep 2009 11:50 On Monday 07 September 2009, Arjan van de Ven wrote: > it's a shameless plug since I wrote it, but latencytop will be able to > tell you what your bottleneck is... > and that is very interesting to know, regardless of the "what scheduler > code" discussion; I'm very much aware of that and I've tried pinning it down a few times, but failed to come up with anything conclusive. I plan to make a new effort in this context as the freezes have increasingly been annoying me. Unfortunately latencytop only shows a blank screen when used with BFS, but I guess that's not totally unexpected. Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Diego Calleja on 7 Sep 2009 12:00 On Lunes 07 Septiembre 2009 17:24:29 Xavier Bestel escribi�: > Except on your typical smartphone, which will run linux and probably > vastly outnumber the number of "traditional" linux desktops. Smartphones will probably start using ARM dualcore cpus the next year, the embedded land is no SMP-free. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jens Axboe on 7 Sep 2009 13:40
On Mon, Sep 07 2009, Ingo Molnar wrote: > > * Jens Axboe <jens.axboe(a)oracle.com> wrote: > > > On Mon, Sep 07 2009, Jens Axboe wrote: > > > Scheduler Runtime Max lat Avg lat Std dev > > > ---------------------------------------------------------------- > > > CFS 100 951 462 267 > > > CFS-x2 100 983 484 308 > > > BFS > > > BFS-x2 > > > > Those numbers are buggy, btw, it's not nearly as bad. But > > responsiveness under compile load IS bad though, the test app just > > didn't quantify it correctly. I'll see if I can get it working > > properly. > > What's the default latency target on your box: > > cat /proc/sys/kernel/sched_latency_ns > > ? It's off right now, but it is set to whatever is the default. I don't touch it. > And yes, it would be wonderful to get a test-app from you that would > express the kind of pain you are seeing during compile jobs. I was hoping this one would, but it's not showing anything. I even added support for doing the ping and wakeup over a socket, to see if the pipe test was doing well because of the sync wakeup we do there. The net latency is a little worse, but still good. So no luck in making that app so far. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |