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: Mike Galbraith on 10 Sep 2009 07:30 On Thu, 2009-09-10 at 13:24 +0200, Jens Axboe wrote: > On Thu, Sep 10 2009, Mike Galbraith wrote: > > xmodmap doesn't seem to be running in this sample. > > That's weird, it was definitely running. I did: > > sleep 1; xmodmap .xmodmap-carl > > in one xterm, and then switched to the other and ran the sched_debug > dump. I have to do it this way, as X will not move focus once xmodmap > starts running. It could be that xmodmap is mostly idle, and the real > work is done by Xorg and/or xfwm4 (my window manager). Hm. Ok, I'll crawl over it, see if anything falls out. -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:30 On Thu, Sep 10 2009, Mike Galbraith wrote: > On Thu, 2009-09-10 at 13:09 +0200, Jens Axboe wrote: > > 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. > > xmodmap doesn't seem to be running in this sample. That's weird, it was definitely running. I did: sleep 1; xmodmap .xmodmap-carl in one xterm, and then switched to the other and ran the sched_debug dump. I have to do it this way, as X will not move focus once xmodmap starts running. It could be that xmodmap is mostly idle, and the real work is done by Xorg and/or xfwm4 (my window manager). -- 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:30 On Thu, 2009-09-10 at 13:09 +0200, Jens Axboe wrote: > 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. xmodmap doesn't seem to be running in this sample. -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:40 On Thu, Sep 10 2009, Mike Galbraith wrote: > On Thu, 2009-09-10 at 13:24 +0200, Jens Axboe wrote: > > On Thu, Sep 10 2009, Mike Galbraith wrote: > > > > xmodmap doesn't seem to be running in this sample. > > > > That's weird, it was definitely running. I did: > > > > sleep 1; xmodmap .xmodmap-carl > > > > in one xterm, and then switched to the other and ran the sched_debug > > dump. I have to do it this way, as X will not move focus once xmodmap > > starts running. It could be that xmodmap is mostly idle, and the real > > work is done by Xorg and/or xfwm4 (my window manager). > > Hm. Ok, I'll crawl over it, see if anything falls out. That seems to be confirmed with the low context switch rate of the perf stat of xmodmap. If I run perf stat -a to get a system wide collection for xmodmap, I get: Performance counter stats for 'xmodmap .xmodmap-carl': 20112.060925 task-clock-msecs # 1.998 CPUs 629360 context-switches # 0.031 M/sec 8 CPU-migrations # 0.000 M/sec 13489 page-faults # 0.001 M/sec <not counted> cycles <not counted> instructions <not counted> cache-references <not counted> cache-misses 10.067532449 seconds time elapsed And again, system is idle while this is happening. Can't rule out that this is some kind of user space bug of course. -- 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:50
On Thu, 2009-09-10 at 13:35 +0200, Jens Axboe wrote: > On Thu, Sep 10 2009, Mike Galbraith wrote: > > On Thu, 2009-09-10 at 13:24 +0200, Jens Axboe wrote: > > > On Thu, Sep 10 2009, Mike Galbraith wrote: > > > > > > xmodmap doesn't seem to be running in this sample. > > > > > > That's weird, it was definitely running. I did: > > > > > > sleep 1; xmodmap .xmodmap-carl > > > > > > in one xterm, and then switched to the other and ran the sched_debug > > > dump. I have to do it this way, as X will not move focus once xmodmap > > > starts running. It could be that xmodmap is mostly idle, and the real > > > work is done by Xorg and/or xfwm4 (my window manager). > > > > Hm. Ok, I'll crawl over it, see if anything falls out. > > That seems to be confirmed with the low context switch rate of the perf > stat of xmodmap. If I run perf stat -a to get a system wide collection > for xmodmap, I get: > > Performance counter stats for 'xmodmap .xmodmap-carl': > > 20112.060925 task-clock-msecs # 1.998 CPUs > 629360 context-switches # 0.031 M/sec > 8 CPU-migrations # 0.000 M/sec > 13489 page-faults # 0.001 M/sec > <not counted> cycles > <not counted> instructions > <not counted> cache-references > <not counted> cache-misses > > 10.067532449 seconds time elapsed > > And again, system is idle while this is happening. Can't rule out that > this is some kind of user space bug of course. All I'm seeing so far is massive CPU usage for dinky job. -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/ |