Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2617430pxb; Tue, 12 Oct 2021 10:01:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw+XIQiRVmXocS52OOGOvKDlp6Q6hEQCLjNRLQFeMXQMejNT38kbpj6csWmdKkxN/B466wC X-Received: by 2002:a50:e044:: with SMTP id g4mr1287786edl.46.1634058075506; Tue, 12 Oct 2021 10:01:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634058075; cv=none; d=google.com; s=arc-20160816; b=tB8e0sKBv0qDd5dZmgN1HXNORjPo6wFbCXPu6yEVlE2fW6NlYS8BVp6C43VG+SvdUZ sADWx4NKKnjFEJvJqse06pUP/1lRR1VQA58ammYTiiTlupIBUkcBK6XxAz6ecly43AYW TJqC0XQhx3NugGFNBTyHep1NJpWlz3f9aLvCvfFuHOuGu8Ty1eD1WoeItDMey+LzU7bP v/K3xWbThBRSi6ng6aNEFt7yO1onP/igHkybTfmblk7qE9XNkWYpVqH1xPCaM/B6Ms11 GQFZxReYp2qvifvOIZmxMQhPeu3rzPnZ3iHR+HaGV6TzGIk0c66iahRXgLCRZKuxN6Vt BHxQ== 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=RwN146AUSaOTW6vverLgeQ1SjqmSoxyKuytXCZPH2HI=; b=pck9OLKstHjAaqjOWZvJ2tip/7J7eYCRV7n7c1WBgPVNH9HXE2CXr7g2vYapurKs7a VTGRTltodwzQzcVwr3e91BvDdo+dicO6E8HZtoTHavdR6RiqF9zysR8L68vxmv3zeTV1 3Rzw0599IZ++eIgWklIsZGwkuXY9gG6sEZ6mRALfpXbY6gZlxKF/LVrtzv+0Vg2J3VRQ yH2cZ+It841TArmuBum4ROr6bo132Kf6Q/og5+ifW1WGgiE4AhyjFvUzBuGYsRYGskBW iP4N9lamUZFw3yoGuNr1oA3zusDHenyhdfWl7ujRwPPR4p3zAwt4GTiv8dksRY/sfY32 dUlg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@posk.io header.s=google header.b=WEfGp4kc; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t1si15707586edt.280.2021.10.12.10.00.43; Tue, 12 Oct 2021 10:01:15 -0700 (PDT) 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=@posk.io header.s=google header.b=WEfGp4kc; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231808AbhJLRAt (ORCPT + 99 others); Tue, 12 Oct 2021 13:00:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229510AbhJLRAs (ORCPT ); Tue, 12 Oct 2021 13:00:48 -0400 Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CF278C061570 for ; Tue, 12 Oct 2021 09:58:46 -0700 (PDT) Received: by mail-ua1-x92d.google.com with SMTP id i22so4049538ual.10 for ; Tue, 12 Oct 2021 09:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posk.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RwN146AUSaOTW6vverLgeQ1SjqmSoxyKuytXCZPH2HI=; b=WEfGp4kcrc24fKYaMmGLQAH39Us7Qkouwgv4+3jU1CNigdxw7HpJW8F8355yHtIhKy 0rXJhxJegbSd96EwStj2PGJ6T2xabIwn06PAvT8Xah0KyR46kSraN8N55cxikuNwM/8g jtU8r8ft8mA7qqNEALSHkFZbr9oI+3/DBqmqJ6AV1FYCm77+LMy5JaVmdUMd+HQm7PZw tgvFo9q/kE+jXCweeiPmHBBBJddyHBVp1w/YaJzGlKi6I8qsJI9aspCI5lGR8dKasJVr HHMI3FRc1V59i3CvVBRPjiw2VNxSFVQ+aU969GZ9kPgp+qY4IKZQ5RcySU6BvFcAXoHd tfqw== 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=RwN146AUSaOTW6vverLgeQ1SjqmSoxyKuytXCZPH2HI=; b=I0v1X3uavVDlo6w+DvH/Vw1jt08rToxznPWGu4eb2BZ2mTWQicI51Waait3YsJ2WMI WpPwz6eFjhAcqFMNFWRPfBWMI3wkLjuSHt4l6ymUO9ZTtmZW293h62AkhiIvQHL3iTKO KSyUJW2w3GRJ10eD8ZXOqyY8+rbqS6riR5FKZWLTM9KIc3yRpqnc1X+HGMcEU+ofJs2f iCZm9AlEyq3041eD2mWufMYuV0yzky8JYuSoKjUH4S0jS4ndLxzpR7cZSG+e9tdtQITI luK7KJ9xcIS0YkJPe+0Wp3QcphVY3YNtrr1UZpyH2DQUFxzZ447kRJfK2RHTzHg4ub8n ZLdQ== X-Gm-Message-State: AOAM532n1KCfvbdM9GAsprGd+5av4glcGpHDklwWmPuGYC179MjlxwP4 hwZixRs5SOrFuhU3dFhJw1QH1eTdLHTaxBh8Xr/2Tw== X-Received: by 2002:ab0:16d4:: with SMTP id g20mr23121662uaf.114.1634057925895; Tue, 12 Oct 2021 09:58:45 -0700 (PDT) MIME-Version: 1.0 References: <20210917180323.278250-1-posk@google.com> <20210917180323.278250-6-posk@google.com> <12eb2300-4a78-9e93-30a3-8e2ddba4693f@uwaterloo.ca> In-Reply-To: From: Peter Oskolkov Date: Tue, 12 Oct 2021 09:58:35 -0700 Message-ID: Subject: Re: [PATCH 5/5 v0.6] sched/umcg: add Documentation/userspace-api/umcg.txt To: Thierry Delisle Cc: Peter Zijlstra , Ingo Molnar , Thomas Gleixner , Linux Kernel Mailing List , linux-api@vger.kernel.org, Paul Turner , Ben Segall , Peter Oskolkov , Andrei Vagin , Jann Horn Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 12, 2021 at 9:25 AM Thierry Delisle wrote: [...] > Just to be clear, sys_umcg_wait supports an operation that, when called > from > a worker, puts the worker to sleep without triggering block detection > or context-switching back to the server? Potentially, yes - when a worker wants to yield (e.g. as part of a custom UMCG-aware mutex/condvar code), and calls into the userspace scheduler, it may be faster to skip the server wakeup (e.g. reassign the server to another sleeping worker and wake this worker). This is not a supported operation right now, but I see how it could be used to optimize some things in the future. Do you have any concerns here? > > > > >> With that said, I'm a little confused by the usage of "yields" in that > >> example. I would expect workers yielding to behave like kernel threads > >> calling sched_yield(), i.e., context switch to the server but also be > >> immediately added to the idle_workers_ptr. > > > > I'm not a fan of arguing about how to name things. If the maintainers > > ask me to rename wait/wake to park/unpark, I'll do that. > > I understand the sentiment, and I'm perfectly happy with the use of > wait/wake. > I was exclusively referring to this one use of "yield" in the > documentation. I don't see a big difference here, sorry. We are mixing levels of abstraction here again, I think. For example, the higher level userspace scheduling code will have more nuanced treatment of IDLE workers; but down at the kernel they are all the same: IDLE worker is a worker that the userspace can "schedule" by marking it RUNNING, regardless of whether the worker is "parked", or "woke from a blocking op", or whatever other semantically different state the worker can be. For the kernel, they are all the same, idle, not runnable, waiting for the userspace to explicitly "schedule" them. Similarly, I don't see a need to semantically distinguish "yield" from "park" at the kernel level of things; this distinction seems to be a higher-level abstraction that can be properly expressed in the userspace, and does not need to be explicitly addressed in the kernel (to make the code faster and simpler, for example).