Hi, Joel,
On Thu, Aug 24, 2023 at 9:22 PM Joel Fernandes joel@joelfernandes.org wrote:
Hello Thomas,
On Thu, Aug 24, 2023 at 12:03:25AM +0200, Thomas Gleixner wrote:
On Thu, Aug 17 2023 at 16:06, Huacai Chen wrote:
On Thu, Aug 17, 2023 at 3:27 AM Joel Fernandes joel@joelfernandes.org wrote:
If do_update_jiffies_64() cannot be used in NMI context,
Can you not make the jiffies update conditional on whether it is called within NMI context?
Which solves what? If KGDB has a breakpoint in the jiffies lock held region then you still dead lock.
Yes, we had already discussed this that jiffies update is not possible from here. There are too many threads since different patch revisions were being reviewed in different threads.
I dislike that..
Is this acceptable?
void rcu_cpu_stall_reset(void) { unsigned long delta;
delta = nsecs_to_jiffies(ktime_get_ns() - ktime_get_coarse_ns()); WRITE_ONCE(rcu_state.jiffies_stall, jiffies + delta + rcu_jiffies_till_stall_check());}
This can update jiffies_stall without updating jiffies (but has the same effect).
Now you traded the potential dead lock on jiffies lock for a potential live lock vs. tk_core.seq. Not really an improvement, right?
The only way you can do the above is something like the incomplete and uncompiled below. NMI safe and therefore livelock proof time interfaces exist for a reason.
Yes, I had already mentioned exactly this issue here of not using an NMI-safe interface: https://lore.kernel.org/all/CAEXW_YT+uw5JodtrqjY0B2xx0J8ukF=FAB9-p5rxgWobSU2... I like your suggestion of using last_jiffies_update though (which as you mentioned needs to be explored more).
There are too many threads which makes the discussion hard to follow. Huacai, it would be great if we can keep the discussions in the same thread (Say for example by passing options like --in-reply-to to "git send-email" command).
I will try my best. In the early time, not all of us were involved. And when I think we are all ready to accept the new solution, I sent a new patch. But unfortunately some others suggest different approaches which make the patch subject change again and again...
Now I tend to use Thomas's method by introducing and using tick_estimate_stale_jiffies(). But let me wait for some time before sending patches.
Huacai
thanks,
- Joel
Thanks,
tglx
--- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c @@ -51,6 +51,13 @@ struct tick_sched *tick_get_tick_sched(i */ static ktime_t last_jiffies_update;
+unsigned long tick_estimate_stale_jiffies(void) +{
ktime_t delta = ktime_get_mono_fast_ns() - READ_ONCE(last_jiffies_update);return delta < 0 ? 0 : div_s64(delta, TICK_NSEC);+}
/*
- Must be called with interrupts disabled !
*/