Wakes of the rcuc/ thread on isolated CPUs.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I noticed this on an older kernel and reproduced it on -rc6: I boot the
(RT) kernel with
	isolcpus=4-15 nohz=on nohz_full=4-15 rcu_nocbs=4-15 rcu_nocb_poll

and compiled a NOHZ_FULL kernel. If I pin a shell onto the isolated CPU
and do nothing then everything seems fine. If I issue commands, this
happens:
   tick_nohz_handler() -> update_process_times() -> rcu_sched_clock_irq()

rcu_sched_clock_irq() invokes rcu_pending() which returns true due to
|         /* Have RCU grace period completed or started?  */
|         if (rcu_seq_current(&rnp->gp_seq) != rdp->gp_seq ||
|             unlikely(READ_ONCE(rdp->gpwrap))) /* outside lock */
|                 return 1;

And it is the first check of the two. Later I see 
|         /* Is the RCU core waiting for a quiescent state from this CPU? */
|         gp_in_progress = rcu_gp_in_progress();
|         if (rdp->core_needs_qs && !rdp->cpu_no_qs.b.norm && gp_in_progress)
|                 return 1;

which triggers it but then "later" it fallbacks to the first case again.
In both cases it wakes the rcuc/ thread on the isolated CPU.

Is this something that needs to happen on the isolated CPU or can this
be excluded for rcu_rdp_is_offloaded() CPUs?

Sebastian




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux