On Wed, 11 May 2022 15:39:56 +0200 Uladzislau Rezki <urezki@xxxxxxxxx> wrote: > <snip> > rcuop/6-54 [000] .N.. 183.753018: rcu_invoke_callback: rcu_preempt rhp=0xffffff88ffd440b0 func=__d_free.cfi_jt > rcuop/6-54 [000] .N.. 183.753020: rcu_invoke_callback: rcu_preempt rhp=0xffffff892ffd8400 func=inode_free_by_rcu.cfi_jt > rcuop/6-54 [000] .N.. 183.753021: rcu_invoke_callback: rcu_preempt rhp=0xffffff89327cd708 func=i_callback.cfi_jt > ... > rcuop/6-54 [000] .N.. 183.755941: rcu_invoke_callback: rcu_preempt rhp=0xffffff8993c5a968 func=i_callback.cfi_jt > rcuop/6-54 [000] .N.. 183.755942: rcu_invoke_callback: rcu_preempt rhp=0xffffff8993c4bd20 func=__d_free.cfi_jt > rcuop/6-54 [000] dN.. 183.755944: rcu_batch_end: rcu_preempt CBs-invoked=2112 idle=>c<>c<>c<>c< > rcuop/6-54 [000] dN.. 183.755946: rcu_utilization: Start context switch > rcuop/6-54 [000] dN.. 183.755946: rcu_utilization: End context switch > <snip> > > i spent some time in order to understand why the context was not switched, > even though the "rcuop" kthread was marked as TIF_NEED_RESCHED and an IPI > was sent to the CPU_0 to reschedule. The last "." in latency field shows > that a context has not disabled any preemption. So everything should be fine. > > An explanation is that a local_bh_disable() modifies the current_thread_info()->preempt.count > so a task becomes non preemtable but the ftrace does not provide any signal about > it. So i was fooled for some time by my tracer logs. > > Do you have any thoughts about it? Should it be solved or signaled > somehow that a task in fact is not preemtable if a counter > 0? Hmm, it should show it in the first part (where the 'd' is). Is this a snapshot from the kernel or from trace-cmd? -- Steve
