linux-kernel - Re: BFS vs. mainline scheduler benchmarks and measurements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090920181041.GC8498@elte.hu>
Date:	Sun, 20 Sep 2009 20:10:41 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Felix Fietkau <nbd@...nwrt.org>
Cc:	Michael Buesch <mb@...sch.de>, Con Kolivas <kernel@...ivas.org>,
	linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Mike Galbraith <efault@....de>
Subject: Re: BFS vs. mainline scheduler benchmarks and measurements


* Felix Fietkau <nbd@...nwrt.org> wrote:

> Ingo Molnar wrote:
> > * Felix Fietkau <nbd@...nwrt.org> wrote:
> > 
> >> Ingo Molnar wrote:
> >> > * Felix Fietkau <nbd@...nwrt.org> wrote:
> >> >> I did some tests with BFS v230 vs CFS on Linux 2.6.30 on a different
> >> >> MIPS device (Atheros AR2317) with 180 MHz and 16 MB RAM. When running
> >> >> iperf tests, I consistently get the following results when running the
> >> >> transfer from the device to my laptop:
> >> >> 
> >> >> CFS: [  5]  0.0-60.0 sec    107 MBytes  15.0 Mbits/sec
> >> >> BFS: [  5]  0.0-60.0 sec    119 MBytes  16.6 Mbits/sec
> >> >> 
> >> >> The transfer speed from my laptop to the device are the same with BFS
> >> >> and CFS. I repeated the tests a few times just to be sure, and I will
> >> >> check vmstat later.
> >> > 
> >> > Which exact mainline kernel have you tried? For anything performance 
> >> > related running latest upstream -git (currently at 202c467) would be 
> >> > recommended.
> >>
> >> I used the OpenWrt-patched 2.6.30. Support for the hardware that I 
> >> tested with hasn't been merged upstream yet. Do you think that the 
> >> scheduler related changes after 2.6.30 are relevant for non-SMP 
> >> performance as well? If so, I'll work on a test with latest upstream 
> >> -git with the necessary patches when I have time for it.
> > 
> > Dont know - it's hard to tell what happens without basic analysis tools. 
> > Is there _any_ way to profile what happens on that system? (Do hrtimers 
> > work on it that could be used to profile it?)
>
> oprofile doesn't have any support for it (mips r4k, no generic 
> perfcounters), the only usable clock source is a simple cpu cycle 
> counter (which is also used for the timer interrupt).

A simple cpu cycle counter ought to be enough to get pretty good 
perfcounters support going on that box.

It takes a surprisingly small amount of code to do that, and a large 
portion of the perf tooling should then work out of box. Here's a few 
example commits of minimal perfcounters support, on other architectures:

 310d6b6: [S390] wire up sys_perf_counter_open
 2d4618d: parisc: perf: wire up sys_perf_counter_open
 19470e1: sh: Wire up sys_perf_counter_open.

Takes about 15 well placed lines of code, if there are no other 
complications on MIPS ;-)

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/