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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 51550C433FE for ; Tue, 12 Oct 2021 16:58:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2792060EBB for ; Tue, 12 Oct 2021 16:58:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231873AbhJLRAu (ORCPT ); Tue, 12 Oct 2021 13:00:50 -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-Google-Smtp-Source: ABdhPJxcBwHriDcJ7ZDs2Y4NKWqE6CUB3TpUzaDRfrP0/5ER7f7GXZEh1KUBr5bmm02/fPidg9pkSnc33DT9QQ3HaXw= 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).