From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by sourceware.org (Postfix) with ESMTPS id 0E09D3848032 for ; Thu, 20 May 2021 12:27:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0E09D3848032 Received: by mail-lf1-x12e.google.com with SMTP id r5so24199409lfr.5 for ; Thu, 20 May 2021 05:27:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EImFjyfxQ58kbRLo7xXR3jU00ItL1CnkOgUj4KfWzDU=; b=Xgonp53O9ifk+/PmpP95+lyUGVKex1J5Rv5Q1xyO48bI8x3qdaOzv6PFhOEw/kxg/9 nFawGWkBPoJ1MhkTyW0S7BTNYEPpyC5te9QvgOD3hdXn8yXeNeJS/73Wz+Pwjq9GutAo hEcFASxCU0LxA7nOGcjmkoI6mAeamVakMyZuui71UIqmUXy2VSq01f8C1H5Sky4RPjGt tK63ZALcDGe314gZI6dtQqeKPmT8aZPjUx12Y11arKGcB+DtDV0BAOvgJKGlp6XXeFD8 3jd5udAyyFqxkTOxeLY6dp49AYXUKPsd//7RIAFn8wrN7WO9ff4ztPVhZTl9ew/Et+vd Oujg== X-Gm-Message-State: AOAM531wCcciBxICmfdVJhxU80NvfJlB7nGwEhBkHaTKlWdo+esmzwuA vbwozwfgeUaW87MXtsrIm7CKkCm5qIYFkR3zIfQ= X-Google-Smtp-Source: ABdhPJyXOeLtz6E0e+DscNFDV4iDBcObp/4inyJguG9UBpUVbBy7c5YvPFW6Sowe8Ily443PKRywByjKTZpXBFVGMzA= X-Received: by 2002:a19:488f:: with SMTP id v137mr3315618lfa.6.1621513671443; Thu, 20 May 2021 05:27:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Godmar Back Date: Thu, 20 May 2021 08:27:39 -0400 Message-ID: Subject: Re: Yield to specific thread? To: Alexandre Bique Cc: William Tambe via Libc-help Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2021 12:27:54 -0000 On Thu, May 20, 2021 at 7:42 AM Alexandre Bique via Libc-help 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).