Re: irq 16: nobody cared

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Sun, Apr 21, 2013 at 09:06:55PM +0200, Borislav Petkov wrote:
> On Sun, Apr 21, 2013 at 11:56:09AM -0700, Paul E. McKenney wrote:
> > CONFIG_RCU_FAST_NO_HZ will definitely change the timing, for example,
> > increasing grace-period durations by up to a factor of four.
> >
> > One way to figure out if this is the problem would be to either (1)
> > apply the following patch (assuming you have no more than a few tens
> > of CPUs)
> 
> Only 8 - I'm modest that way :)

;-) ;-) ;-)

> > or (2) setting the sysfs rcutree.rcu_expedited variable to 1 just before
> > suspending the system.
> > 
> > Either approach will force RCU to always use the faster expedited
> > grace periods for synchronize_rcu() and friends.  They will -not- help
> > if someone has open-coded synchronize_rcu() in terms of call_rcu(),
> > though.
> 
> Right,
> 
> # echo 1 > /sys/kernel/rcu_expedited
> 
> helped.
> 
> No warning, no delay, 2 suspend/resume cycles back-to-back. So, a
> probable fix could be to force-enable the expedited grace periods during
> suspend...?

Fix for the slowness, for sure!

For the irq warning, it is most likely simply hiding the problem.

Still, speeding up suspend sounds valuable.  The connection between
suspending and expediting grace periods probably needs to be in
the kernel -- people will undoubtedly want to expedite them for short
periods of time at runtime, like when starting wireshark, and it would
be good to minimize unnecessary dependency on scripting.

It would not be hard to provide an in-kernel primitive for expediting.

Hmmm...  When you resume, is the expediting still set?  (Can't see why
it would not be.)  If so, it would be good to have some way of disabling
it after boot completes.  Which, as noted in another thread, requires
that RCU be informed of when boot completes.  ;-)

							Thanx, Paul

> Hmmm.
> 
> Thanks.
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> Sent from a fat crate under my desk. Formatting is fine.
> --
>