Re: Yield to specific thread?

[Godmar Back <godmar@gmail.com>]

On Thu, May 20, 2021 at 7:42 AM Alexandre Bique via Libc-help
<libc-help@sourceware.org> wrote:
>
> Hi,
>
> I'm working on a soft real-time problem, for audio processing.
>
> We have 2 processes A and B.
> A produces a request, B processes it and produces a response, A consumes it.
>
> The whole thing is synchronous so it looks like
>    result = process(request);
> except that we execute the process function in another process for
> isolation purposes.
>
> Right now, we put everything into SHM, and A writes a lightweight request
> into a pipe which B is blocking on using read(); and another pipe to notify
> A about the result.
>
> On the papers this approach works but in practice we are facing scheduling
> issues.
> I read some of the Linux kernel and if I understood correctly the kernel
> does not schedule right away the threads waiting on I/O but put them in a
> wake up queue, and they will be woken up by the scheduler on the next
> scheduler_tick() which depends on the scheduler tick frequency. On a low
> latency kernel the frequency is about 1000Hz which is not too bad, but on
> most desktops it is lower than that, and it produces jitter.
>

I don't think that's correct.  If a task is woken up, it can be
scheduled right away.
For instance, say you have a 2-core machine, with 2 tasks running,
task A assigned
to core 1, task B assigned to core 2, a woken-up task will run
immediately (if you ignore
the time it tasks for the necessary IPI).

If tasks A and B are on the same CPU/core, it may or may not be run immediately.
Under CFS, if its virtual runtime is smallest (that is, it has the
highest priority), it would preempt.
But more likely in this case is this (assuming A and B are the only
tasks on the CPU/core):
A signals B, which does not preempt A, and soon after A will do
something that makes it
block - at that point, B is scheduled on that core.

But in the absence of other ready-to-run tasks, Linux will not lay
idle and wait for a scheduler_tick
to schedule a task that has just become ready - that would be
considered a kernel bug.

Also, if you must have thread B run once woken up, no matter what, put
it in a higher
scheduling class (SCHED_FIFO or SCHED_RR).