Messages in this thread | | | Date | Sun, 22 Jun 2008 23:24:06 +0200 | From | "Vegard Nossum" <> | Subject | Re: [PATCH -tip-rcu] Make rcutorture more vicious: make quiescent rcutorture less power-hungry |
| |
On Sun, Jun 22, 2008 at 10:58 PM, Vegard Nossum <vegard.nossum@gmail.com> wrote: > On Sun, Jun 22, 2008 at 10:06 PM, Paul E. McKenney > <paulmck@linux.vnet.ibm.com> wrote: >> This patch makes the non-module rcutorture a bit more friendly to >> the power-conservation code. This is a rather simple-minded approach. >> More sophisticated approaches would get rid of the rcutorture tasks >> while rcutorture execution was suppressed, but attempts thus far to >> do this have not gone well -- calling rcu_torture_init() from a /proc >> callout results in oopses. > > Hi Paul, > > I applied your three patches > > [PATCH] Make rcutorture more vicious: add stutter feature > [PATCH] Make rcutorture more vicious: reinstate boot-time testing > [PATCH -tip-rcu] Make rcutorture more vicious: make quiescent > rcutorture less power-hungry > > to v2.6.26-rc7 and gave it a quick testing in qemu. But it seems to > hang during gdb self-tests at boot:
Okay, you might disregard that. I'm typing on the very same kernel running on a real machine now, so I assume that it's just qemu's fault. (Actually, setting the number of cpus to 2 instead of 3 would run the kgdb tests, but with a lot of warnings). But qemu is known to have been buggy with these things before. (Sorry for the noise.)
Vegard
-- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036
| |