Linus Torvalds (torvalds.delete@this.linux-foundation.org) on August 23, 2018 12:46 pm wrote:
> .. so what about realtime? Just throw that out the window?

Like many things this wouldn't apply or wouldn't work in realtime or maybe it still works if the effect is bounded (or for example if you only shorten slices, never extend them).

> What about page faults that need to do IO?

Then a sleep/switch occurs, it's only best effort QoI type thing.

> What about any number of things that simply force the process to be scheduled?

Then a switch occurs, it's only best effort QoI type thing.


> And since you have to force-evict at some point anyway, whatever issue you tried
> to prevent is still there, and so the process can't rely on it anyway.

Yes, of course - but now instead of getting a latency spike 100% of the time when a lock-holding thread gets switched out, you get it the microscopic amount of time one of the above issues occurs (and if are smart you'll try to avoid the cases you know about).

> So it's completely idiotic and pointless. All you added was a grace period non-guarantee that doesn't guarantee
> anything at all, but that made people perhaps think it did, and probably incorrectly rely on it.

It is not idiotic and no one was asking for a guarantee. This not an rseq-type thing that allows you to use some guarantee to implement something differently: it's a QoS type thing where you say "vary the process quantum slightly to improve observed latencies", just like the quantum may already be varied for other reasons e.g., to improve interactivity.

> If you don't see why that is stupid, I can't help you.

Well put me in the same boat.

Keep in mind I (and probably Paul, although I don't want to speak for him) am making an "there exists" argument: there exists some type of lock-using processes for which context switching a thread holding a lock is painful and these processes could benefit from slight timeslice shortening or lengthening if it reduced that chance. I'm not saying this applies to every or most processes. I'm not saying put this in pthreads by default.

As far as this limited argument goes, I already know it is basically true because I've seen people jump through hoops to reduce this effect, usually in user-space but at least once also with kernel hacks. These changes "worked" in terms of a latency reduction. Sure maybe they could have also redesigned their application to change the contention characteristic, but that's just a facile answer for any locking problem, isn't it? These weren't stupid people.