Messages in this thread | | | Date | Fri, 2 Jul 2021 11:28:05 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH v2 1/1] psi: stop relying on timer_pending for poll_work rescheduling |
| |
On Thu, Jul 01, 2021 at 09:28:04AM -0700, Suren Baghdasaryan wrote: > On Thu, Jul 1, 2021 at 9:12 AM Peter Zijlstra <peterz@infradead.org> wrote: > > > > On Thu, Jul 01, 2021 at 09:09:25AM -0700, Suren Baghdasaryan wrote: > > > On Thu, Jul 1, 2021 at 1:59 AM Peter Zijlstra <peterz@infradead.org> wrote: > > > > > > > > On Wed, Jun 30, 2021 at 01:51:51PM -0700, Suren Baghdasaryan wrote: > > > > > + /* cmpxchg should be called even when !force to set poll_scheduled */ > > > > > + if (atomic_cmpxchg(&group->poll_scheduled, 0, 1) && !force) > > > > > return; > > > > > > > > Why is that a cmpxchg() ? > > > > > > We want to set poll_scheduled and proceed with rescheduling the timer > > > unless it's already scheduled, so cmpxchg helps us to make that > > > decision atomically. Or did I misunderstand your question? > > > > What's wrong with: atomic_xchg(&group->poll_scheduled, 1) ? > > Yes, since poll_scheduled can be only 0 or 1 atomic_xchg should work > fine here. Functionally equivalent but I assume atomic_xchg() is more > efficient due to no comparison.
Mostly conceptually simpler; the cmpxchg-on-0 makes that you have to check if there's ever any state outside of {0,1}. The xchg() thing is the classical test-and-set pattern.
On top of all that, the cmpxchg() can fail, which brings ordering issues.
Typically, I think, you want to ensure that everything that happens before psi_schedule_poll_work() is visible to the work when it runs (also see Johannes' email). In case poll_scheduled is already 1, the cmpxchg will fail and *NOT* provide that ordering. Meaning the work might not observe the latest changes. xchg() doesn't have this subtlety.
| |