Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp884245pxt; Fri, 6 Aug 2021 16:56:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxedO82hZ9LcWMkghJFqCiI5LV4WAZOzA0WY1uXORfZrCCvPeHRKzXkcIbNlapem95tckuj X-Received: by 2002:a05:6e02:10a:: with SMTP id t10mr803917ilm.52.1628294203065; Fri, 06 Aug 2021 16:56:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628294203; cv=none; d=google.com; s=arc-20160816; b=NdinCVGxu16c1w3iKRMto+dPpwTmjfS3XMQJPgWz95FdkhQ+0u76Dmmei5IgjAEnX3 i7d6xg7UsISOIy4zZFZdKOK+9KQNaEwLpfsmzs3ITDh78j+/AzKO3GcJPo4ck0ElkzHJ 20mMXTJVqioSaqgXtmxi8YTjYdCOmqS5In5oteaFdDjfR6uLZp/eT6JYJpCqBxn/n9I2 Mpec3GQJJIySvFTTB/VH4WWihvddDe26Qb4rIXU7jYuYy5oToeLjilFWDnlN0wEIFx5b mLPHNlY0wGZAjoBVxAJTW8XoOIshUhzZGVBpP3KTQWoYe8MX+5oS1Vny3xqORsDO0I7B Cxpg== 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=ZEV2xzdFoPsyTOxL8t4/rUKDR02bQVEVN3guKtT+wRY=; b=WeEr8aMstX2OtrKyZx2Gl2A7+ysjsO8aG0waVM+e2bQR7WFs+Tl9epySEA27SDG2Fn aPtqmTS77YjRF94kSH2HX26pWv8qpeksoWd7xO1yAvzR6IHBgND51sMOc+ovAt2WNmtp oUIfshE9oNS/EYpW6ZVYAQrjBWVP6p9CaYupxaBg0oA4+qru+DYTcx2iT7uTiJxbQM0b jSFpYgkcweIKOZ+NB1U4WDLIkBTBBiVCQ8Ps327D4DSR3LQMa1VU2x9/ZHqBCKODR9wS Y6DLZ0Xn3CXQMwhSHTwdvXd2cw80osJn7B+73jBj8Db/ZbY3XJljWNdRE2rVKVum/CAJ MhgA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=STFv+5Rz; 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 a9si2259358jat.116.2021.08.06.16.56.31; Fri, 06 Aug 2021 16:56:43 -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=@google.com header.s=20161025 header.b=STFv+5Rz; 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 S241117AbhHFRZc (ORCPT + 99 others); Fri, 6 Aug 2021 13:25:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42042 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240927AbhHFRZc (ORCPT ); Fri, 6 Aug 2021 13:25:32 -0400 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D96FDC061798 for ; Fri, 6 Aug 2021 10:25:15 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id g30so15057309lfv.4 for ; Fri, 06 Aug 2021 10:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZEV2xzdFoPsyTOxL8t4/rUKDR02bQVEVN3guKtT+wRY=; b=STFv+5RzBr6aFH1qe0BeaS395jREDWeGc143CKC9CxIAt6DkCl51f8Q3Nvu4J8NhyS TiYGIfWqfI8kYjv16tWiF9bp/xD7cvjUfW+Bs1W5G+Z4ZC5B6t8LXXqUNf8JJsNHLA2k rNV0pEpEgtWI+P4ICAUdt3eihcvAuwK1Zd7xxFxKqdmyIn9PgL9aVm7o967H7wMYL+xV gA7bgHkaVLHq9+Sh8p+ppFDweRf9v3zDBvfoGpRkz91UnrSVrtyqY3brAh+RzHfxPEph pTmQv/HmDMWIKnUhWJcXDbnJ/0AxRxh2IcZT+NSNioEsiyD+/2/tpF2ii4Dk+ChD6nD1 Zm8g== 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=ZEV2xzdFoPsyTOxL8t4/rUKDR02bQVEVN3guKtT+wRY=; b=fhW1mbLCMzqRBN4rbLTrEGbHfkHToaZ23+cHM/1Sz6YEmcIhqKpY//nIVj680pGMjq vtcxuG7dyYjoRhozma/yxdZiYoUVAIRQGUqZFDtE5V+zqe/fZQ6LDd7EsKBaq/h/JqG8 d1c/uDD/cUfmF/6Nj5VpcEYabKmhJGHnZI3cBfyRtb7Q/E3jnVmwOCL9W1Bs6Q7Hx5AZ RnnRmnhR5uehiVaKzpRCUFwbFUMIzvjzud9F11desIPhLvYbus5JONNaK5LQLp8SU+9U FQzaUR4jRsGDHAtCkCNMlOosCDgyZ14LEB6ncxVZgUBv3pGS9Ep019yJXEmlVlWHaeS1 s6bA== X-Gm-Message-State: AOAM530v4hdmMtP51pgG5Dh9LYYaVpvuunnXEcyhIVYAvuTg+sq4KkgY Mr5svrOjYznDpqRxxxs+mAayhj7sj6lKrz70ID/Crw== X-Received: by 2002:ac2:46fb:: with SMTP id q27mr8012789lfo.209.1628270713989; Fri, 06 Aug 2021 10:25:13 -0700 (PDT) MIME-Version: 1.0 References: <1dc64d75-da9b-272a-a9ab-7d2ae7a85764@uwaterloo.ca> In-Reply-To: <1dc64d75-da9b-272a-a9ab-7d2ae7a85764@uwaterloo.ca> From: Peter Oskolkov Date: Fri, 6 Aug 2021 10:25:02 -0700 Message-ID: Subject: Re: [PATCH 3/4 v0.4] sched/umcg: add Documentation/userspace-api/umcg.rst To: Thierry Delisle Cc: avagin@google.com, bsegall@google.com, jannh@google.com, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, mingo@redhat.com, pabuhr@uwaterloo.ca, peterz@infradead.org, pjt@google.com, posk@posk.io, tglx@linutronix.de Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 6, 2021 at 9:52 AM Thierry Delisle wrote: > > > All _umcg_ state changes here happen in the userspace before > > sys_umcg_wait() is called. So: > > > > W1: cmpxchg W1:RUNNING => W1:IDLE > > - if OK, call sys_umcg_wait() > > - if failed, do something else (notes below) > > > > W2: cmpxchg W1:IDLE => W1:RUNNING > > - if OK, lock itself, set W2:next_tid to W1, call sys_umcg_wait() > > (will not block nor spin), restore next_tid and state/unlock upon > > syscall return > > - if failed, do something else > > I am talking about the case where both cmpxchg() succeed and W2 sets > *both* UMCG_WAIT_WAKE_ONLY and UMCG_WAIT_WF_CURRENT_CPU. More > specifically, if things are ordered like so: (ideally use monospace font) > > - w1 - - w2 - > > w1:RUNNING => w1:IDLE|L | > S:IDLE => S:RUNNING | > sys_umcg_wait(): | > set ~UMCG_TF_LOCKED | > | w1:IDLE => w1:RUNNING|L > | w2:RUNNING => w2:IDLE|L > | w2:next_tid := W1.tid > | w1:RUNNING|L => w1:RUNNING > | sys_umcg_wait(): > | set ~UMCG_TF_LOCKED > | do_context_switch() > idle_loop() | > > What does ttwu() do with w1 if it has not reached idle_loop yet? If both cmpxchg() succeeded, but W1 was never put to sleep, ttwu() will do nothing and W1 will continue running on its initial CPU, while W2 will continue running on its own CPU. WF_CURRENT_CPU is an advisory flag, and in this situation it will not do anything. > > I am not familiar with the details of kernel context-switching, but in > user-level threading, more specifically Cforall, this would be a problem. > Between the call to do_context_switch() and and idle_loop(), there is a > window where 2 CPUs run the same thread at the same time. One thread is > performing the front side of the context switch and the other threads > wakes up on the backside of the context switch. This behaviour invariably > corrupts the program stack of that thread. Again, I do not know if that > applies here. I am not exactly sure how the program stack is handled when > inside a system call. This is a wake, not a context switch, right? I'm not sure why you are concerned with context switching here. And even if it were a context switch, the kernel manages thread stacks properly, there's nothing to worry about. Am I missing something?