Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp499878pxm; Fri, 25 Feb 2022 12:19:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJwyBvtsDda7WJ5VMO1iwBNUp7TXmEfioSHPqnE+uZ6nj1X+/KHWco2KcXrp0zEI+DLnG/EF X-Received: by 2002:a05:6a00:1687:b0:4e1:45d:3ded with SMTP id k7-20020a056a00168700b004e1045d3dedmr9353913pfc.0.1645820386042; Fri, 25 Feb 2022 12:19:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645820386; cv=none; d=google.com; s=arc-20160816; b=zcwkvDdixTCnRr8VhxPZPM0N94EYRTpLmboMe9eAhKvTdNQuCcqKUgaFt+7lvu9y0b CcckEeS8U7SxlUngWfXDOYlAeRB6sImnEp5DARGtxk4ID/jD2bMnDMTreGNvTtKpyaPO Uo8fYDXy2bv0+cxEBygx3IR3i34BcksQV9rMGBXQIb4rRCsVzwvHqXYTHrcjXOZeIESN lrCspB/LYohgJDRAXL4q6W9EqXeoJF3MOOnAMcBqQqBZHQB1zXT6547+elWtPj/rrbqj Izls1QP23zCSW38VBnUcG8zyueafvVbJ/ie+AcvFGvh3LqqjlBhYP61bw+4fwOGL4I2E U11w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature:dkim-filter; bh=xVDx4/GSY2zJkyT/gM/R6AZuIZFKi2N/VNg2nDidNbU=; b=azPDIExuuIiM5sjBeeAhX65+MrslINojE5JHycrvBI+kL6VeZG7+X0Q6r7Q8W8aVKD 7zTUyO5ClhAbXfuU1S765Rt/AygkELlGD9FDlxySyfnOfSIiQi29iww3XkolcoNOQn4v M759tanXsV3H3nb57oqHMPb7J2IvoplFj1EEyAR63OeQgggY4Ywu+/DKOao9DCX6zCrO BJyTHJ3apQSOVvOhotoG3RvlnjlstDnjVhEdnbVuvQuAEQLtTFtc9F546BAZC79mT/XC 9o+yAu6tZaxDKzfJyMejn6g1wX0wI3/XXAFy2TWLjQyACv4uz4DI32RpyaDG+odfXIIa Sr3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lwn.net header.s=20201203 header.b=Ypngwjhd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x13-20020a170902e04d00b0014f3a39ab28si2403489plx.494.2022.02.25.12.19.30; Fri, 25 Feb 2022 12:19:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@lwn.net header.s=20201203 header.b=Ypngwjhd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243784AbiBYRgF (ORCPT + 99 others); Fri, 25 Feb 2022 12:36:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243779AbiBYRgD (ORCPT ); Fri, 25 Feb 2022 12:36:03 -0500 Received: from ms.lwn.net (ms.lwn.net [45.79.88.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BEAEE1BA90C for ; Fri, 25 Feb 2022 09:35:30 -0800 (PST) Received: from localhost (unknown [IPv6:2601:281:8300:104d::5f6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id E3D3E2A0; Fri, 25 Feb 2022 17:35:29 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 ms.lwn.net E3D3E2A0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lwn.net; s=20201203; t=1645810530; bh=xVDx4/GSY2zJkyT/gM/R6AZuIZFKi2N/VNg2nDidNbU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=YpngwjhdB/ODio2/bgj3wh3cWagorZlvDWa3zRG/E9hD5L4S4afRgCTmOxpo3VIiK JOabr1BqSrAcu0mZSP942hBbpU+iJywDZByt9PN7ORkJPW2Inm/kJymcQd3mgwGZ8u Qtp+cxLsC5DjIVBLJPWIItPdJDkwFmDuNA3q3fk3cf56KftaaMgM9q/nIA0R39PWgZ Z1t57DOZ372qkYwh0+RqVnJZuU06khcA1XEZJdX2IWMai+yGhZN9iLcA5L9NohsiNC phOk6QuxjvauwlapB+kfqbLRkq3+YprCGSsmzmtko97nRLZWIoMOxhx48fyB7yobor 94o/rDUN7yM3Q== From: Jonathan Corbet To: Mathieu Desnoyers , Peter Zijlstra Cc: linux-kernel@vger.kernel.org, Thomas Gleixner , "Paul E . McKenney" , Boqun Feng , "H . Peter Anvin" , Paul Turner , linux-api@vger.kernel.org, Christian Brauner , Florian Weimer , David.Laight@ACULAB.COM, carlos@redhat.com, Peter Oskolkov , Mathieu Desnoyers Subject: Re: [RFC PATCH v2 09/11] sched: Introduce per memory space current virtual cpu id In-Reply-To: <20220218210633.23345-10-mathieu.desnoyers@efficios.com> References: <20220218210633.23345-1-mathieu.desnoyers@efficios.com> <20220218210633.23345-10-mathieu.desnoyers@efficios.com> Date: Fri, 25 Feb 2022 10:35:29 -0700 Message-ID: <87k0dikfxa.fsf@meer.lwn.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mathieu Desnoyers writes: > This feature allows the scheduler to expose a current virtual cpu id > to user-space. This virtual cpu id is within the possible cpus range, > and is temporarily (and uniquely) assigned while threads are actively > running within a memory space. If a memory space has fewer threads than > cores, or is limited to run on few cores concurrently through sched > affinity or cgroup cpusets, the virtual cpu ids will be values close > to 0, thus allowing efficient use of user-space memory for per-cpu > data structures. So I have one possibly (probably) dumb question: if I'm writing a program to make use of virtual CPU IDs, how do I know what the maximum ID will be? It seems like one of the advantages of this mechanism would be not having to be prepared for anything in the physical ID space, but is there any guarantee that the virtual-ID space will be smaller? Something like "no larger than the number of threads", say? Thanks, jon