Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1190138pxb; Fri, 21 Jan 2022 11:52:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJxZjHSlhn87Ltg4tmpjVtB9WahcLABCEDDl8slhSnal4z6+vLwnqfVHPKnCL/Rf5FcivEdg X-Received: by 2002:a17:902:e88a:b0:14a:19f6:6396 with SMTP id w10-20020a170902e88a00b0014a19f66396mr5109729plg.95.1642794745815; Fri, 21 Jan 2022 11:52:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642794745; cv=none; d=google.com; s=arc-20160816; b=sKRjfwZip+acdOOu6cDzR+xcNM1WXLAO3Gq23NBFP57bAFjV6078ZOVELWakRqZbI0 myqsLauCrGh/Gk9BY/d/7Qi7/SV23+LWdpLSqPMLPtn3xxCtwH8QwiaZGaRc9ia4DSmM 9qiTnO6/mDMjn1SGR8zDsH3WP6RlqLMexlBVTFanKYzdU4OZJ8kLIOlgH11UmyJbOOnt RIEOPBqw6EX9uccOAtHhGbrVofPO2XhqQ4vn81gR/2f38Y9XeltExnJx5c53ty1Tm466 Z6fxYNZNlqxvvMiteUKkOeE1ozk+7XiJJyAbvfaVbOOI5/74vIt8gR0TOxohDWFYwcdM YP/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=SEZuid1kBdUhkeCpk54LJW3gbPrX55D+4zhbEvARjRw=; b=zHUmAnCrIol4yBftvg/P47AQwLpF6NBznbAC9xE/LzVCavYe4KJFbf6NyUSDzTCl1g jJ4QR8MX74Zxnf9hJs5OMN65dvHgABqc1KsZW0TmoNMY4bx0SM/vUhK6J9CAmmxq2Toa JjiAEEtXEzS/TxL01C7er8+XXAQmYTY5SBmlpMFFxutaH9kxETmlE4Ym+PsKp0lke3OM y3Fx6MvndoVH8M7yl5ooAeq51sa9UpL7VwBB9qi3nlZG5lB+TLquVx7WVoth0MSSD8Cx yVcem9GiZMcmTxvYq6UmxF7p59n7lqrBNKCPLMEQXSexc4sT6ey00mBnAWsGDGYgPATh 2+Tw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="OsIaM/vz"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id om4si14927222pjb.48.2022.01.21.11.52.13; Fri, 21 Jan 2022 11:52:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="OsIaM/vz"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1356388AbiASR0z (ORCPT + 99 others); Wed, 19 Jan 2022 12:26:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57746 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236719AbiASR0y (ORCPT ); Wed, 19 Jan 2022 12:26:54 -0500 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 22E05C061574 for ; Wed, 19 Jan 2022 09:26:54 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id c66so6507085wma.5 for ; Wed, 19 Jan 2022 09:26:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SEZuid1kBdUhkeCpk54LJW3gbPrX55D+4zhbEvARjRw=; b=OsIaM/vzswRNN97ZqsOpKgGxJry0M6NaTwqFj/J27sTZw9N/4c0NNC5JB5nDiKbJQL YCHveYFW1+VXOK9vxJ1IiTxp5XSkgGU/v6O3O/jJzcKGPweZlZWLmtbdOX0SHCzloYms YYQNCuemIOJ+46aZwsoV6I3/bR8wpoLpoQmafarZM5abWGoeJ+XVWAS3pya/vctHbgen li7iEOhHp67hE7vCd/93AllAkBK32Bp49EPEpE8VlhW85EGfUwiV43i67meEOCNHCHYb HO5yvEAHZP2zoDrmSb1Os+71jKUmhOJ9ZXpQT/IDnh379Cl8HmoQbNvGre+E4gqqvzlm KG4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SEZuid1kBdUhkeCpk54LJW3gbPrX55D+4zhbEvARjRw=; b=yNDLvy2ZkgKtyIiP38x7dlgDmkfcJ6cuZI2AaMMyNw1knEKzmL22RNO8sMbb+PFMid 9FXjFwurSBirclKl/yk6SQvn4613OQnh5X64ccIjGH+RAuX+wkN6baHhkZSnFcsHPrUv p1KSfn3Y4H99z12Yj7vfVKij+Ll4jnapS4WTxXBJe5wJfyCBAe+BsvScb3W7FPZksZG/ LKmaXFpqI7aPREQsW22nte1dbW8cE5NnpH9s8BSBqr5pVswrGKVKLkpD9Uig2Lg56+gY 4VuNdcmCI9/tCeRbQD2zc9gaDdYvCsM++QOPpoFkWe7S9Y3y+1B+vz7WZCpPwg/T2Oup gOGg== X-Gm-Message-State: AOAM5334kkdWmU5mmc8fJXgtJ/KCRI7GbSzCTXrmk3keKmZOTyMig/um +s34/hbopvgbuxRzRcyVAP+5dTsSpC9Ak5zmPMe6lw== X-Received: by 2002:a1c:a70f:: with SMTP id q15mr4540357wme.78.1642613212579; Wed, 19 Jan 2022 09:26:52 -0800 (PST) MIME-Version: 1.0 References: <20211122211327.5931-1-posk@google.com> <20211122211327.5931-4-posk@google.com> <20211124200822.GF721624@worktop.programming.kicks-ass.net> In-Reply-To: From: Peter Oskolkov Date: Wed, 19 Jan 2022 09:26:41 -0800 Message-ID: Subject: Re: [PATCH v0.9.1 3/6] sched/umcg: implement UMCG syscalls To: Peter Zijlstra Cc: Peter Oskolkov , Ingo Molnar , Thomas Gleixner , Andrew Morton , Dave Hansen , Andy Lutomirski , Linux Memory Management List , Linux Kernel Mailing List , linux-api@vger.kernel.org, Paul Turner , Ben Segall , Andrei Vagin , Jann Horn , Thierry Delisle Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 6, 2021 at 3:47 AM Peter Zijlstra wrote: > > On Mon, Nov 29, 2021 at 09:34:49AM -0800, Peter Oskolkov wrote: > > On Mon, Nov 29, 2021 at 8:41 AM Peter Zijlstra wrote: > > > > Also, timeout on sys_umcg_wait() gets you the exact same situation (or > > > worse, multiple running workers). > > > > It should not. Timed out workers should be added to the runnable list > > and not become running unless a server chooses so. So sys_umcg_wait() > > with a timeout should behave similarly to a normal sleep, in that the > > server is woken upon the worker blocking, and upon the worker wakeup > > the worker is added to the woken workers list and waits for a server > > to run it. The only difference is that in a sleep the worker becomes > > BLOCKED, while in sys_umcg_wait() the worker is RUNNABLE the whole > > time. > > > > Why then have sys_umcg_wait() with a timeout at all, instead of > > calling nanosleep()? Because the worker in sys_umcg_wait() can be > > context-switched into by another worker, or made running by a server; > > if the worker is in nanosleep(), it just sleeps. > > I've been trying to figure out the semantics of that timeout thing, and > I can't seem to make sense of it. > > Consider two workers: > > S0 running A S1 running B > > therefore: > > S0::state == RUNNABLE S1::state == RUNNABLE > A::server_tid == S0.tid B::server_tid = S1.tid > A::state == RUNNING B::state == RUNNING > > Doing: > > self->state = RUNNABLE; self->state = RUNNABLE; > sys_umcg_wait(0); sys_umcg_wait(10); > umcg_enqueue_runnable() umcg_enqueue_runnable() sys_umcg_wait() should not enqueue the worker as runnable; workers are enqueued to indicate wakeup events. > umcg_wake() umcg_wake() > umcg_wait() umcg_wait() > hrtimer_start() > > In both cases we get the exact same outcome: > > A::state == RUNNABLE B::state == RUNNABLE > S0::state == RUNNING S1::state == RUNNING > S0::runnable_ptr == &A S1::runnable_ptr = &B So without sys_umcg_wait enqueueing into the queue, the state now is A::state == RUNNABLE B::state == RUNNABLE S0::state == RUNNING S1::state == RUNNING S0::runnable_ptr == NULL S1::runnable_ptr = NULL > > > Which is, AFAICT, the exact state you wanted to achieve, except B now > has an active timer, but what do you want it to do when that goes? When the timer goes off, _then_ B is enqueued into the queue, so the state becomes A::state == RUNNABLE B::state == RUNNABLE S0::state == RUNNING S1::state == RUNNING S0::runnable_ptr == NULL S1::runnable_ptr = &B So worker timeouts in sys_umcg_wait are treated as wakeup events, with the difference that when the worker is eventually scheduled by a server, sys_umcg_wait returns with ETIMEDOUT. > > I'm tempted to say workers cannot have timeout, and servers can use it > to wake themselves.