Linus Torvalds (torvalds.delete@this.linux-foundation.org) on August 21, 2018 2:34 pm wrote:
> Paul A. Clayton (paaronclayton.delete@this.gmail.com) on August 21, 2018 9:09 am wrote:
> > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on August 20, 2018 4:29 pm wrote:
> > >
> > > Linux now (merged into the latest released kernel version, 4.18) actually has
> > > what could be seen as the reverse of that: "rseq" aka restartable sequences.
> > >
> > > It doesn't disable preemption (which is crazy and all kinds of stupid), but it does
> > > allow user space to see if it has been preempted, and mark certain sequences to
> > > be done atomically. And if preemption happens, the sequence gets aborted.
> >
> > Since threads have phases that benefit from not being significantly interrupted, I think there
> > would be value to allowing a thread to express that a phase would extend beyond the normally
> > allotted time slice
>
> No.
>
> People will just misuse that, and then you need a lot of BS code to prevent misuses etc.
>
> Don't do it. There is no upside anyway.

No upside? I think you underestimate the cost of an occasional context switch while a thread is holding a hot lock.

Especially for heavily threaded applications that care more about tail/worst-case latencies, a switch like that even if rare in relative terms (e.g., threads normally spend 99.99% of their time outside the lock) can lead to a lot of outliers as every other thread bangs up against the lock until pretty much every other thread has been scheduled and the holding thread runs again.

The you better hope like hell your locks are unfair (enough) or else that state can persist indefinitely (if they are unfair it should sort it self out unless you are unlucky).

Of course you could say "redesign your application" or "use less threads" but that's pretty much a vacuous answer.

Some applications would probably much prefer that a thread's timeslice was cut very slightly short if it reduced the chance of a switch while holding a lock to almost zero. I've seen green-thread JITs that do something like that since they are better able to introspect the running process and decide "ok, better let this guy get out of this lock before scheduling other threads". Of course green-thread JITs suck for other reasons but this is one thing they could sometimes do well.