On Wed, 5 Feb 2025 10:07:36 +0100
Peter Zijlstra [off-list ref] wrote:

quoted

This is where we will disagree for the reasons I explained in my second
email. This feature affects other tasks. And no, making it 20us doesn't
make it better. Because from what I get from you, if we implement this, it
will be available for all preemption methods (including PREEMPT_RT), where
we do have less than 50us latency, and and even a 20us will break those
applications.  

Then pick another number; RT too has a max scheduling latency number (on
some random hardware). If you stay below that, all is fine. 

So we set it to 1us?

Or does this have to calculate what that latency number is for each random
hardware?

quoted

This was supposed to be only a hint to the kernel, not a complete feature  

That's a contradiction in terms -- even a hint is a feature.

Yes, a hint is a feature, I meant "complete feature" meaning it being not
just a hint, but guaranteed to do something.

quoted

that is hard coded and will override how other tasks behave.   

Everything has some effect. My point is that if you limit this effect to
be less than what it can already effect, you're not making things worse.

quoted

As system
calls themselves can make how things are scheduled depending on the
preemption method,  

What?

Read my last email:

  https://lore.kernel.org/all/20250204100555.1a641b9b@gandalf.local.home/ (local)

I went into this in detail.

quoted

I didn't want to add something that will change how
things are scheduled that ignores the preemption method that was chosen.  

Userspace is totally oblivious to the preemption method chosen, and it
damn well should be.

Agreed, and user space doesn't have to know what preemption method was
chosen for this. Where does this say that it needs to know?

All this does is to give the kernel a hint that it is in a critical section
and the kernel decides to grant some more time or not.

The preemption method will influence that decision, but user space doesn't
need to be know.

-- Steve