On Tue, Jun 16, 2020 at 08:24:37PM -0400, Joel Fernandes wrote: > Hi, > I am seeing something a bit strange with RCU where it is trying to > start a GP twice from a CPU even though no new CB was queued on that > CPU. It is quite possible that I'm missing something. Anyway, I wrote > a patch to add some tracing when CBs are queued into the segcb. I am > planning to post this trace patch later. > > The trace in the link below shows CPU2 queuing around 5 CBs, which > then gets accelerated at 5.192123. The GP thread running on CPU3 > starts a new GP. Now the CPU2 softirq runs again (roughly 1ms after > the previous acceleration). The softirq runs probably because the GP > thread is expecting a QS report from CPU 2. When the CPU2's softirq > runs though, it does an acceleration again which triggers a second new > GP start. This seems a bit unnecessary AFAICS - because the need for > GP *832 was already recorded which is all CPU2 should really be caring > about right? > > Here is the trace: https://pastebin.com/raw/AYGzu1g4 Assuming that the WAIT= and NEXT_READY= numbers are grace-period numbers, this trace is expected behavior for two sets of callbacks, one that arrived at CPU 2 by time 5.192121 and another that arrived between then and time 5.193131. So I have to ask... What tells you that no callbacks arrived at CPU 2 during this interval? On the other hand, if CPU 2 is offloaded, what you might be seeing is the delayed drain of callbacks from the bypass. Thanx, Paul
