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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C196CC433FE for ; Thu, 17 Nov 2022 19:10:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234730AbiKQTKr (ORCPT ); Thu, 17 Nov 2022 14:10:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56652 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231240AbiKQTKr (ORCPT ); Thu, 17 Nov 2022 14:10:47 -0500 Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5AC666035C for ; Thu, 17 Nov 2022 11:10:46 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id h193so2825426pgc.10 for ; Thu, 17 Nov 2022 11:10:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=vWIMIJOLR1ZWP39J9pWvnWbHjuvpXRyJAoGNGTtOVYI=; b=EQwEPuLgzqoeTKcS7jmfdO1ts/EI4TuE1KFLzpSYgKpRdkHrkzO8YvoL5CXrFCgkgM RWENzn3GNhTboobst1d+kvL3HAHHIYliEMYopWa0nMuRYWOJAM7zHZSihydj8tMSwfPT 7Mbu2XmUDBniPYl1i3bJudB7CEAhox1GM6xOhrpgcVuKwHmMkFacyl6ZIc1ReWMLmh6N 1/D5un05T65bD6c03whgTPgnpTNDOWWrbhN+vAdFFwuG/RUgC2ml6nC9qiykbfzAE/NM wyw4lb2zr38xXeIMCOIqbspEj6lhYFSpOC1j80AQ7vBI5yfUBJVZD73HU1UpSQHzYm3f PaDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vWIMIJOLR1ZWP39J9pWvnWbHjuvpXRyJAoGNGTtOVYI=; b=aKxCiA7qP0IcQ7qd7ncceLptlgBpjk9KmjPnGiVl27BkaCRKgdjeUM7XsaX/y7P0zf IVOwjPZIP4wJsacSw4jBXDy7dJlqDQsNTDOfW493bDTz1wlPBzQAU7s/iUYKfJKJLif3 VXWFE3HKYNYkdPexH7/mOYMy9QT0WzTOH/48l+QWGIGduYFJRlrQkqOIBWRDB9DwoH2E QMuaxwM67J9YYpzqWRHPjMrqaUe9NbJrRdWNEQJKOCSCEUlPXkPp+ZZXFfY/Mw3ge31P TqePPT5Uxi7E99grSLCkz1USrep3N4oxxMzBJUcZfRb3lgD8+6eyWffIEFzVrWVSBhWf h5HA== X-Gm-Message-State: ANoB5pnhWNoNs3Luuu2obkFgO+Cmes5fOlUzG5UKRDcwMx9vzPBQmk59 9MkjPA7dfTeo4MgK8SFBU1u8rQ== X-Google-Smtp-Source: AA0mqf6P4WdUgFu5uypTYxFGUm6JCIFL4DiQGiM+DvuY36mevs4XCEDFbK83+RPxg837oTFGmj9LMA== X-Received: by 2002:a62:1a05:0:b0:56c:1277:d056 with SMTP id a5-20020a621a05000000b0056c1277d056mr4278757pfa.23.1668712245558; Thu, 17 Nov 2022 11:10:45 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id v185-20020a622fc2000000b0053e38ac0ff4sm1501912pfv.115.2022.11.17.11.10.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Nov 2022 11:10:45 -0800 (PST) Date: Thu, 17 Nov 2022 19:10:41 +0000 From: Sean Christopherson To: Mathieu Desnoyers Cc: Andy Lutomirski , Peter Zijlstra , 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 , Alexander Mikhalitsyn , Chris Kennelly Subject: Re: [PATCH v5 08/24] sched: Introduce per memory space current virtual cpu id Message-ID: References: <20221103200359.328736-1-mathieu.desnoyers@efficios.com> <20221103200359.328736-9-mathieu.desnoyers@efficios.com> <2f191ddb-de89-52c0-e7da-26ac0239b8fe@efficios.com> <273f4883-25bc-44ad-9c35-3950ca8a3fcf@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <273f4883-25bc-44ad-9c35-3950ca8a3fcf@efficios.com> Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Thu, Nov 17, 2022, Mathieu Desnoyers wrote: > On 2022-11-14 15:49, Sean Christopherson wrote: > > On Fri, Nov 11, 2022, Mathieu Desnoyers wrote: > > > On 2022-11-10 23:41, Andy Lutomirski wrote: > > > > On Thu, Nov 3, 2022 at 1:05 PM Mathieu Desnoyers > > > > wrote: > > > > Also, in my mind "virtual cpu" is vCPU, which this isn't. Maybe > > > > "compacted cpu" or something? It's a strange sort of concept. > > > > > > I've kept the same wording that has been introduced in 2011 by Paul Turner > > > and used internally at Google since then, although it may be confusing if > > > people expect kvm-vCPU and rseq-vcpu to mean the same thing. Both really end > > > up providing the semantic of a virtually assigned cpu id (in opposition to > > > the logical cpu id on the system), but this is much more involved in the > > > case of KVM. > > > > I had the same reaction as Andy. The rseq concepts don't worry me so much as the > > existence of "vcpu" in mm_struct/task_struct, e.g. switch_mm_vcpu() when switching > > between KVM vCPU tasks is going to be super confusing. Ditto for mm_vcpu_get() > > and mm_vcpu_put() in the few cases where KVM currently does mmget()/mmput(). > > I'm fine with changing the wording if it helps make things less confusing. > > Should we go for "compact-cpu-id" ? "packed-cpu-id" ? Other ideas ? What about something like "process-local-cpu-id" to capture that the ID has meaning only within the associated address space / process?