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: Jens Axboe on 10 Sep 2009 06:20 On Thu, Sep 10 2009, Ingo Molnar wrote: > > * Jens Axboe <jens.axboe(a)oracle.com> wrote: > > > On Thu, Sep 10 2009, Ingo Molnar wrote: > > > > > > * Ingo Molnar <mingo(a)elte.hu> wrote: > > > > > > > > However, the interactivity problems still remain. Does that > > > > > mean it's not a latency issue? > > > > > > > > It means that Jens's test-app, which demonstrated and helped us > > > > fix the issue for him does not help us fix it for you just yet. > > > > > > Lemme qualify that by saying that Jens's issues are improved not > > > fixed [he has not re-run with latest latt.c yet] but not all things > > > are fully fixed yet. For example the xmodmap thing sounds > > > interesting - could that be a child-runs-first effect? > > > > I thought so too, so when -tip failed to boot I pulled the patches > > from Mike into 2.6.31. It doesn't change anything for xmodmap, > > though. > > Note, you can access just the pristine scheduler patches by checking > out and testing tip:sched/core - no need to pull them out and apply. > > Your crash looks like clocksource related - that's in a separate > topic which you can thus isolate if you use sched/core. I'm building sched/core now and will run the xmodmap test there. -- 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/
From: Jens Axboe on 10 Sep 2009 06:30 On Thu, Sep 10 2009, Jens Axboe wrote: > On Thu, Sep 10 2009, Ingo Molnar wrote: > > > > * Jens Axboe <jens.axboe(a)oracle.com> wrote: > > > > > On Thu, Sep 10 2009, Ingo Molnar wrote: > > > > > > > > * Ingo Molnar <mingo(a)elte.hu> wrote: > > > > > > > > > > However, the interactivity problems still remain. Does that > > > > > > mean it's not a latency issue? > > > > > > > > > > It means that Jens's test-app, which demonstrated and helped us > > > > > fix the issue for him does not help us fix it for you just yet. > > > > > > > > Lemme qualify that by saying that Jens's issues are improved not > > > > fixed [he has not re-run with latest latt.c yet] but not all things > > > > are fully fixed yet. For example the xmodmap thing sounds > > > > interesting - could that be a child-runs-first effect? > > > > > > I thought so too, so when -tip failed to boot I pulled the patches > > > from Mike into 2.6.31. It doesn't change anything for xmodmap, > > > though. > > > > Note, you can access just the pristine scheduler patches by checking > > out and testing tip:sched/core - no need to pull them out and apply. > > > > Your crash looks like clocksource related - that's in a separate > > topic which you can thus isolate if you use sched/core. > > I'm building sched/core now and will run the xmodmap test there. No difference. Then I tried switching NO_NEW_FAIR_SLEEPERS on, and then I get: Performance counter stats for 'xmodmap .xmodmap-carl': 9.009137 task-clock-msecs # 0.447 CPUs 18 context-switches # 0.002 M/sec 1 CPU-migrations # 0.000 M/sec 315 page-faults # 0.035 M/sec <not counted> cycles <not counted> instructions <not counted> cache-references <not counted> cache-misses 0.020167093 seconds time elapsed Woot! -- 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/
From: Mike Galbraith on 10 Sep 2009 07:00 On Thu, 2009-09-10 at 12:28 +0200, Jens Axboe wrote: > No difference. Then I tried switching NO_NEW_FAIR_SLEEPERS on, and then > I get: > > Performance counter stats for 'xmodmap .xmodmap-carl': > > 9.009137 task-clock-msecs # 0.447 CPUs > 18 context-switches # 0.002 M/sec > 1 CPU-migrations # 0.000 M/sec > 315 page-faults # 0.035 M/sec > <not counted> cycles > <not counted> instructions > <not counted> cache-references > <not counted> cache-misses > > 0.020167093 seconds time elapsed > > Woot! Something is very seriously hosed on that box... clock? Can you turn it back on, and do.. while sleep .1; do cat /proc/sched_debug >> foo; done ...on one core, and (quickly;) xmodmap .xmodmap-carl, then send me a few seconds worth (gzipped up) to eyeball? -Mike -- 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 10 Sep 2009 07:10 On Thu, Sep 10 2009, Con Kolivas wrote: > > It probably just means that latt isn't a good measure of the problem. > > Which isn't really too much of a surprise. > > And that's a real shame because this was one of the first real good attempts > I've seen to actually measure the difference, and I thank you for your > efforts Jens. I believe the reason it's limited is because all you're > measuring is time from wakeup and the test app isn't actually doing any work. > The issue is more than just waking up as fast as possible, it's then doing > some meaningful amount of work within a reasonable time frame as well. What > the "meaningful amount of work" and "reasonable time frame" are, remains a > mystery, but I guess could be added on to this testing app. Here's a quickie addition that adds some work to the threads. The latency measure is now 'when did I wake up and complete my work'. The default work is filling a buffer with pseudo random data and then compressing it with zlib. Default is 64kb of data, can be adjusted with -x. -x0 turns off work processing. -- Jens Axboe
From: Jens Axboe on 10 Sep 2009 07:10
On Thu, Sep 10 2009, Mike Galbraith wrote: > On Thu, 2009-09-10 at 12:28 +0200, Jens Axboe wrote: > > > No difference. Then I tried switching NO_NEW_FAIR_SLEEPERS on, and then > > I get: > > > > Performance counter stats for 'xmodmap .xmodmap-carl': > > > > 9.009137 task-clock-msecs # 0.447 CPUs > > 18 context-switches # 0.002 M/sec > > 1 CPU-migrations # 0.000 M/sec > > 315 page-faults # 0.035 M/sec > > <not counted> cycles > > <not counted> instructions > > <not counted> cache-references > > <not counted> cache-misses > > > > 0.020167093 seconds time elapsed > > > > Woot! > > Something is very seriously hosed on that box... clock? model name : Genuine Intel(R) CPU T2400 @ 1.83GHz Throttles down to 1.00GHz when idle. > Can you turn it back on, and do.. I guess you mean turn NEW_FAIR_SLEEPERS back on, correct? > while sleep .1; do cat /proc/sched_debug >> foo; done > ..on one core, and (quickly;) xmodmap .xmodmap-carl, then send me a few > seconds worth (gzipped up) to eyeball? Attached. -- Jens Axboe |