On Mon, Jun 11, 2007 at 10:18:06AM -0700, Paul E. McKenney wrote:
> On Mon, Jun 11, 2007 at 08:55:27AM -0700, Paul E. McKenney wrote:
> > On Mon, Jun 11, 2007 at 05:38:55PM +0200, Ingo Molnar wrote:
> > >
> > > * Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> > >
> > > > > hm, what affinity do they start out with? Could they all be pinned
> > > > > to CPU#0 by default?
> > > >
> > > > They start off with affinity masks of 0xf on a 4-CPU system. I would
> > > > expect them to load-balance across the four CPUs, but they stay all on
> > > > the same CPU until long after I lose patience (many minutes).
> > >
> > > ugh. Would be nice to figure out why this happens. I enabled rcutorture
> > > on a dual-core CPU and all the threads are spread evenly.
> >
> > Here is the /proc/cpuinfo in case this helps. I am starting up a test
> > on a dual-core CPU to see if that works better.
>
> And this quickly load-balanced to put a pair of readers on each CPU.
> Later, it moved one of the readers so that it is now running with
> one reader on one of the CPUs, and the remaining three readers on the
> other CPU.
>
> Argh... this is with 2.6.21-rt1... Need to reboot with 2.6.21.4-rt12...
OK, here are a couple of snapshots from "top" on a two-way system.
It seems to cycle back and forth between these two states.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20126 root 39 19 0 0 0 R 47 0.0 11:38.62 rcu_torture_rea
20129 root 39 19 0 0 0 R 47 0.0 13:28.06 rcu_torture_rea
20127 root 39 19 0 0 0 R 43 0.0 12:39.83 rcu_torture_rea
20128 root 39 19 0 0 0 R 43 0.0 11:50.58 rcu_torture_rea
20121 root 39 19 0 0 0 R 10 0.0 2:59.69 rcu_torture_wri
20123 root 39 19 0 0 0 D 2 0.0 0:28.52 rcu_torture_fak
20125 root 39 19 0 0 0 D 2 0.0 0:28.47 rcu_torture_fak
20122 root 39 19 0 0 0 D 1 0.0 0:28.38 rcu_torture_fak
20124 root 39 19 0 0 0 D 1 0.0 0:28.41 rcu_torture_fak
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20129 root 39 19 0 0 0 R 80 0.0 14:46.56 rcu_torture_rea
20126 root 39 19 0 0 0 R 33 0.0 12:52.70 rcu_torture_rea
20128 root 39 19 0 0 0 R 33 0.0 13:01.50 rcu_torture_rea
20127 root 39 19 0 0 0 R 33 0.0 13:49.68 rcu_torture_rea
20121 root 39 19 0 0 0 R 13 0.0 3:16.82 rcu_torture_wri
20122 root 39 19 0 0 0 R 2 0.0 0:31.16 rcu_torture_fak
20123 root 39 19 0 0 0 R 2 0.0 0:31.25 rcu_torture_fak
20124 root 39 19 0 0 0 D 2 0.0 0:31.23 rcu_torture_fak
20125 root 39 19 0 0 0 R 2 0.0 0:31.25 rcu_torture_fak
12907 root 20 0 12576 1068 796 R 1 0.0 0:08.55 top
The "preferred" state is the first one. But given that the readers
will consume all CPU available to them, the scheduler might not be
able to tell the difference.
Perhaps the fakewriters are confusing the scheduler, will try again on
a 4-CPU machine leaving them out.
Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
