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: Nikos Chantziaras on 8 Sep 2009 06:50 On 09/08/2009 01:12 PM, Ingo Molnar wrote: > > * Nikos Chantziaras<realnc(a)arcor.de> wrote: > >> On 09/08/2009 11:04 AM, Ingo Molnar wrote: >>> >>> * Pekka Pietikainen<pp(a)ee.oulu.fi> wrote: >>> >>>> On Mon, Sep 07, 2009 at 10:57:01PM +0200, Ingo Molnar wrote: >>>>>>> Could you profile it please? Also, what's the context-switch rate? >>>>>> >>>>>> As far as I can tell, the broadcom mips architecture does not have >>>>>> profiling support. It does only have some proprietary profiling >>>>>> registers that nobody wrote kernel support for, yet. >>>>> Well, what does 'vmstat 1' show - how many context switches are >>>>> there per second on the iperf server? In theory if it's a truly >>>>> saturated box, there shouldnt be many - just a single iperf task >>>> >>>> Yay, finally something that's measurable in this thread \o/ >>> >>> My initial posting in this thread contains 6 separate types of >>> measurements, rather extensive ones. Out of those, 4 measurements >>> were latency oriented, two were throughput oriented. Plenty of >>> data, plenty of results, and very good reproducability. >> >> None of which involve latency-prone GUI applications running on >> cheap commodity hardware though. [...] > > The lat_tcp, lat_pipe and pipe-test numbers are all benchmarks that > characterise such workloads - they show the latency of context > switches. > > I also tested where Con posted numbers that BFS has an edge over > mainline: kbuild performance. Should i not have done that? It's good that you did, of course. However, when someone reports a problem/issue, the developer usually tries to reproduce the problem; he needs to see what the user sees. This is how it's usually done, not only in most other development environments, but also here from I could gather by reading this list. When getting reports about interactivity issues and with very specific examples of how to reproduce, I would have expected that most developers interested in identifying the issue would try to reproduce the same problem and work from there. That would mean that you (or anyone else with an interest of tracking this down) would follow the examples given (by me and others, like enabling desktop compositing, firing up mplayer with a video and generally reproducing this using the quite detailed steps I posted as a recipe). However, in this case, instead of the above, raw numbers are posted with batch jobs and benchmarks that aren't actually reproducing the issue as described by the reporter(s). That way, the developer doesn't get to experience the issue firt-hand (and due to this possibly missing the real cause). In most other bug reports or issues, the right thing seems to happen and the devs try to reproduce it exactly as described. But not in this case. I suspect this is due to most devs not using the software components on their machines that are necessary for this and therefore it would take too much time to reproduce the issue exactly as described? -- 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: Juergen Beisert on 8 Sep 2009 07:40 On Dienstag, 8. September 2009, Nikos Chantziaras wrote: > On 09/08/2009 11:38 AM, Arjan van de Ven wrote: > > On Tue, 08 Sep 2009 10:19:06 +0300 > > > > Nikos Chantziaras<realnc(a)arcor.de> wrote: > >> latencytop has this to say: > >> > >> http://foss.math.aegean.gr/~realnc/pics/latop1.png > >> > >> Though I don't really understand what this tool is trying to tell me, > >> I hope someone does. > > > > despite the untranslated content, it is clear that you have scheduler > > delays (either due to scheduler bugs or cpu contention) of upto 68 > > msecs... Second in line is your binary AMD graphics driver that is > > chewing up 14% of your total latency... > > I've now used a correctly installed and up-to-date version of latencytop > and repeated the test. Also, I got rid of AMD's binary blob and used > kernel DRM drivers for my graphics card to throw fglrx out of the > equation (which btw didn't help; the exact same problems occur). > > Here the result: > > http://foss.math.aegean.gr/~realnc/pics/latop2.png > > Again: this is on an Intel Core 2 Duo CPU. Just an idea: Maybe some system management code hits you? jbe -- Pengutronix e.K. | Juergen Beisert | Linux Solutions for Science and Industry | Phone: +49-8766-939 228 | Vertretung Sued/Muenchen, Germany | Fax: +49-5121-206917-5555 | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ | -- 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: Nikos Chantziaras on 8 Sep 2009 07:40 On 09/08/2009 02:54 AM, Thomas Fjellstrom wrote: > On Sun September 6 2009, Nikos Chantziaras wrote: >> [...] >> For reference, my system is: >> >> CPU: Intel Core 2 Duo E6600 (2.4GHz) >> Mainboard: Asus P5E (Intel X38 chipset) >> RAM: 6GB (2+2+1+1) dual channel DDR2 800 >> GPU: RV770 (Radeon HD4870). >> > > My Phenom 9550 (2.2Ghz) whips the pants off my Intel Q6600 (2.6Ghz). I and a > friend of mine both get large amounts of stalling when doing a lot of IO. I > haven't seen such horrible desktop interactivity since before the new > schedulers and the -ck patchset came out for 2.4.x. Its a heck of a lot better > on my AMD Phenom's, but some lag is noticeable these days, even when it wasn't > a few kernel releases ago. It seems someone tried BFS on quite slower hardware: Android. According to the feedback, the device is much more responsive with BFS: http://twitter.com/cyanogen -- 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: Ingo Molnar on 8 Sep 2009 07:40 * Nikos Chantziaras <realnc(a)arcor.de> wrote: > [...] That would mean that you (or anyone else with an interest of > tracking this down) would follow the examples given (by me and > others, like enabling desktop compositing, firing up mplayer with > a video and generally reproducing this using the quite detailed > steps I posted as a recipe). Could you follow up on Frederic's detailed tracing suggestions that would give us the source of the latency? ( Also, as per lkml etiquette, please try to keep the Cc: list intact when replying to emails. I missed your first reply that you un-Cc:-ed. ) A quick look at the latencytop output suggests a scheduling latency. Could you send me the kernel .config that you are using? Ingo -- 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: el_es on 8 Sep 2009 08:10
Ingo Molnar <mingo <at> elte.hu> writes: > For example 'Compile' latencies: > > --- Benchmarking simulated cpu of Audio in the presence of simulated Load > Latency +/- SD (ms) Max Latency % Desired CPU % Deadlines Met > v2.6.30: Compile 0.003 +/- 0.00426 0.014 100 100 > BFS: Compile 0.007 +/- 0.00751 0.019 100 100 > > but ... with a near 100% standard deviation that's pretty hard to > judge. The Max Latency went from 14 usecs under v2.6.30 to 19 usecs > on BFS. > [...] > Ingo > This just struck me : maybe what desktop users *feel* is exactly that : current approach is too fine-grained, trying to achieve the minimum latency with *most* reproductible result (less stddev) at all cost ? And BFS just doesn't care? I know this sounds like heresy. [ the space below is to satisfy the brain-dead GMane posting engine]. Lukasz -- 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/ |