Re: RCU related performance regression in 3.3

[Paul E. McKenney]

On Wed, Apr 18, 2012 at 05:00:14PM +0200, Pascal Chapperon wrote:
> Le 18/04/2012 16:01, Paul E. McKenney a écrit :
> >On Wed, Apr 18, 2012 at 11:37:28AM +0200, Pascal Chapperon wrote:
> >>Mount and umount operations are not slower with RCU_FAST_NO_HZ during
> >>runtime; systemctl start and stop operations are also not slower. In
> >>fact, i couldn't find a single operation slower during runtime with
> >>RCU_FAST_NO_HZ.
> >
> >Your boot-time setup is such that all CPUs are online before the
> >boot-time mount operations take place, right?
> Yes :
> [    0.242697] Brought up 8 CPUs
> [    0.242699] Total of 8 processors activated (35118.33 BogoMIPS).
> 
> > Struggling to understand
> >how RCU can tell the difference between post-CPU-bringup boot time
> >and run time...
> >
> systemd is controlling the whole boot process including mount
> operation (apart root filesystem) and as I can see, uses heavily
> sockets to do it (not to mention cpu-affinity). It controls also the
> major part of umount operations. Is it possible that your patch hits
> a systemd bug ?

Is it possible that systemd is using network operations that include
synchronize_rcu()?  Then if you did the same operation from the
command line at runtime, you might not see the slowdown.

Is it possible for you to convince systemd to collect RCU event tracing
during the slow operation?  RCU event tracing is available under
/sys/kernel/debug/tracing/rcu.

> What I don't understand is that systemd coexists well with
> RCU_FAST_NO_HZ on a smaller laptop with older and much less powerful
> cpu.
> I'll do further tests on another machine.

There might well be a timing-related problem.

							Thanx, Paul

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