On Tue, Apr 20, 2021 at 12:41:08PM +0200, Luigi Rizzo wrote: > On Tue, Apr 20, 2021 at 11:14 AM Peter Zijlstra <pet...@infradead.org> wrote:
> > We mostly try and avoid using this stuff wherever possible. Only when > > no other choice is left do we send IPIs. > > > > NOHZ_FULL already relies on this and gets massively unhappy when a new > > user comes and starts to spray IPIs. > > I am curious, why is that -- is it because the new user is stealing > the shared csd's in cfd_data (see below), or some other reason ? The premise of NOHZ_FULL is that it will not be interrupted. There are users who are working on a mode where any interruption will cause a (fatal) signal. > > So no; mostly we send an IPI because we _HAVE_ to, not because giggles. > > > > That said; there's still some places left where we can avoid sending > > IPIs, but in all those cases correctness mandates we actually handle > > things and not randomly not do anything. > > My case too requires that the request is eventually handled, but with > this non-blocking IPI the caller has a better option than blocking: > it can either retry the multicast IPI at a later time if conditions allow, > or it can post a dedicated CSD (with the advantage that being my > requests idempotent, if the CSD is locked there is no need to retry > because it means the handler has not started yet). > > In fact, if we had the option to use dedicated CSDs for multicast IPI, > we wouldn't even need to retry because we'd know that the posted CSD > is for our call back and not someone else's. What are you doing that CSD contention is such a problem?
