On 21/04/20 20:07, Davidlohr Bueso wrote: >> > > I should have looked closer here - I was thinking about the return > value of rcuwait_wait_event. Yes, that signal_pending check you > mention makes the sleep semantics change bogus as interruptible is no > longer just to avoid contributing to the load balance. > > And yes, unfortunately adding prepare_to and finish_rcuwait() looks > like the most reasonable approach to keeping the tracepoint > semantics. I also considered extending rcuwait_wait_event() by > another parameter to pass back to the caller if there was any wait at > all, but that enlarges the call and is probably less generic. Yes, at some point the usual prepare_to/finish APIs become simpler. > I'll send another version keeping the current sleep and tracepoint > semantics. Thanks---and sorry, I should have noticed that way earlier. Paolo
