From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32E84C433F5 for ; Wed, 19 Jan 2022 17:26:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 880316B0072; Wed, 19 Jan 2022 12:26:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8308B6B0073; Wed, 19 Jan 2022 12:26:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F8446B0074; Wed, 19 Jan 2022 12:26:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay038.a.hostedemail.com [64.99.140.38]) by kanga.kvack.org (Postfix) with ESMTP id 637C16B0072 for ; Wed, 19 Jan 2022 12:26:54 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 287E580DD6 for ; Wed, 19 Jan 2022 17:26:54 +0000 (UTC) X-FDA: 79047716748.01.E9D352C Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) by imf31.hostedemail.com (Postfix) with ESMTP id B39F520039 for ; Wed, 19 Jan 2022 17:26:53 +0000 (UTC) Received: by mail-wm1-f45.google.com with SMTP id l35-20020a05600c1d2300b0034d477271c1so6951885wms.3 for ; Wed, 19 Jan 2022 09:26:53 -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=3I0whttIMfwkq8xS4UfcB6CSH413u+VQXGNb/jfPalooAVf4Tt7VOVu9XWRahr9Nx4 8emxvZL6I5LjReiFlm+Ot8JY5BR5m+VQclZHQMJVjkxC8WAP3ja0a1TVbJ5HH+8SyX9A 4qWciJY8Hrwe+Ik3eab6+wJyvy4HSilY5ajrX/TV1rG4oHMdNvlKXrgEMhGC2RxhQW9n CjO5f8vExLZM2mE1lwD0BVy2Gf8CyO6YvM9HXp07mF8cwCY+spCvC7iuvSP5nWQqdH3i CRNNg7F2lMaOINSv5gd8eqfxH6VNy6tq/8KiCApKwCy+RSUmnsHzZ+ZuqIvSJnS5SevA mPsw== X-Gm-Message-State: AOAM533KuAz8Bhdux/zOynXS5/jMZPHtarlZB6nVpzLBTeDl75mAjEAy mJp53bRKttHnavORVLforRWx1NnyqEoR5wYhxqQSQQ== X-Google-Smtp-Source: ABdhPJygQoMrxaannmaE5oT8T2OCMfl70EeVNcl0JCuLJ00UC5fpSLM5m4bqGDsG3gjYlaSNGCjT/Cf2e9JudNHX1SE= 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" X-Rspamd-Queue-Id: B39F520039 X-Stat-Signature: xoi5t6ddoibttagd5dd98jbwtnuy3a9n Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="OsIaM/vz"; spf=pass (imf31.hostedemail.com: domain of posk@google.com designates 209.85.128.45 as permitted sender) smtp.mailfrom=posk@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam07 X-HE-Tag: 1642613213-433280 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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.