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: Frans Pop on 8 Sep 2009 18:40 On Tuesday 08 September 2009, you wrote: > On Wed, Sep 9, 2009 at 6:11 AM, Frans Pop<elendil(a)planet.nl> wrote: > >> Would it be possible to have a command line switch that allows to > >> start the old textual mode? > > > > I got a private reply suggesting that --nogui might work, and it > > does. > > Um. You means that you tested with runlevel 3(multiuser mode). Is it > right? Frans. Can you share me your linux distribution for this test? I > want to check with same conditions(e.g:linux distribution like fedora > 11,ubuntu9.04 , runlevel, and so on.). I ran it from KDE's konsole by just entering 'sudo latencytop --nogui' at the command prompt. Distro is Debian stable ("Lenny"), which does not have differences between runlevels: by default they all start a desktop environment (if a display manager like xdm/kdm/gdm is installed). But if you really want to know, the runlevel was 2 ;-) 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: Nikos Chantziaras on 8 Sep 2009 19:00 On 09/08/2009 05:20 PM, Arjan van de Ven wrote: > On Tue, 08 Sep 2009 13:13:34 +0300 > Nikos Chantziaras<realnc(a)arcor.de> 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. > > > so we finally have objective numbers! > > now the interesting part is also WHERE the latency hits. Because > fundamentally, if you oversubscribe the CPU, you WILL get scheduling > latency.. simply you have more to run than there is CPU. Sounds plausible. However, with mainline this latency is very, very noticeable. With BFS I need to look really hard to detect it or do outright silly things, like a "make -j50". (At first I wrote "-j20" here but then went ahead an tested it just for kicks, and BFS would still let me use the GUI smoothly, LOL. So then I corrected it to "-j50"...) -- 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: Jiri Kosina on 8 Sep 2009 19:30 On Wed, 9 Sep 2009, Nikos Chantziaras wrote: > > > 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? > > I'm not sure what is meant with "system management code." System management interrupt happens when firmware/BIOS/HW-debugger is executed in privilege mode so high, that even OS can't do anything about that. It is used in many situations, such as - memory errors - ACPI (mostly fan control) - TPM OS has small to none possibility to influence SMI/SMM. But if this would be the cause, you should probably obtain completely different results on different hardware configuration (as it is likely to have completely different SMM behavior). -- Jiri Kosina SUSE Labs, Novell Inc. -- 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 19:40 On 09/09/2009 02:20 AM, Jiri Kosina wrote: > On Wed, 9 Sep 2009, Nikos Chantziaras wrote: > >>>> 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? >> >> I'm not sure what is meant with "system management code." > > System management interrupt happens when firmware/BIOS/HW-debugger is > executed in privilege mode so high, that even OS can't do anything about > that. > > It is used in many situations, such as > > - memory errors > - ACPI (mostly fan control) > - TPM > > OS has small to none possibility to influence SMI/SMM. But if this would > be the cause, you should probably obtain completely different results on > different hardware configuration (as it is likely to have completely > different SMM behavior). Wouldn't that mean that a BFS-patched kernel would suffer from this too? In any case, of the above, only fan control is active, and I've run with it disabled on occasion (hot summer days, I wanted to just keep it max with no fan control) with no change. As far as I can tell, the Asus P5E doesn't have a TPM (the "Deluxe" and "VM" models seem to have one.) As for memory errors, I use unbuffered non-ECC RAM which passes a memtest86+ cycle cleanly (well, at least the last time I ran it through one, a few months ago.) -- 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: Benjamin Herrenschmidt on 8 Sep 2009 20:30
> The TLB is SW loaded, yes. However it should not do any misses on kernel > space, since the whole segment is in a wired TLB entry. Including vmalloc space ? Ben. -- 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/ |