public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	"Paul E . McKenney" <paulmck@kernel.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	"H . Peter Anvin" <hpa@zytor.com>, Paul Turner <pjt@google.com>,
	linux-api@vger.kernel.org,
	Christian Brauner <christian.brauner@ubuntu.com>,
	Florian Weimer <fw@deneb.enyo.de>,
	David.Laight@ACULAB.COM, carlos@redhat.com,
	Peter Oskolkov <posk@posk.io>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Subject: Re: [RFC PATCH v2 09/11] sched: Introduce per memory space current virtual cpu id
Date: Fri, 25 Feb 2022 10:35:29 -0700	[thread overview]
Message-ID: <87k0dikfxa.fsf@meer.lwn.net> (raw)
In-Reply-To: <20220218210633.23345-10-mathieu.desnoyers@efficios.com>

Mathieu Desnoyers <mathieu.desnoyers@efficios.com> 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

  parent reply	other threads:[~2022-02-25 17:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-18 21:06 [RFC PATCH v2 00/11] RSEQ node id and virtual cpu id extensions Mathieu Desnoyers
2022-02-18 21:06 ` [RFC PATCH v2 01/11] rseq: Introduce feature size and alignment ELF auxiliary vector entries Mathieu Desnoyers
2022-02-18 21:06 ` [RFC PATCH v2 02/11] rseq: Introduce extensible rseq ABI Mathieu Desnoyers
2022-02-18 21:06 ` [RFC PATCH v2 03/11] rseq: extend struct rseq with numa node id Mathieu Desnoyers
2022-02-18 21:06 ` [RFC PATCH v2 04/11] selftests/rseq: Use ELF auxiliary vector for extensible rseq Mathieu Desnoyers
2022-02-18 21:06 ` [RFC PATCH v2 05/11] selftests/rseq: Implement rseq numa node id field selftest Mathieu Desnoyers
2022-02-18 21:06 ` [RFC PATCH v2 06/11] lib: invert _find_next_bit source arguments Mathieu Desnoyers
2022-02-18 21:06 ` [RFC PATCH v2 07/11] lib: implement find_{first,next}_{zero,one}_and_zero_bit Mathieu Desnoyers
2022-02-18 21:06 ` [RFC PATCH v2 08/11] cpumask: implement cpumask_{first,next}_{zero,one}_and_zero Mathieu Desnoyers
2022-02-18 21:06 ` [RFC PATCH v2 09/11] sched: Introduce per memory space current virtual cpu id Mathieu Desnoyers
2022-02-21 17:38   ` [RFC PATCH v3 " Mathieu Desnoyers
2022-02-25 17:35   ` Jonathan Corbet [this message]
2022-02-25 17:56     ` [RFC PATCH v2 " Mathieu Desnoyers
2022-02-25 18:15       ` Jonathan Corbet
2022-02-25 18:39         ` Mathieu Desnoyers
2022-02-25 19:24           ` Jonathan Corbet
2022-02-25 21:21       ` Mathieu Desnoyers
2022-02-18 21:06 ` [RFC PATCH v2 10/11] rseq: extend struct rseq with per memory space vcpu id Mathieu Desnoyers
2022-02-18 21:06 ` [RFC PATCH v2 11/11] selftests/rseq: Implement rseq vm_vcpu_id field support Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k0dikfxa.fsf@meer.lwn.net \
    --to=corbet@lwn.net \
    --cc=David.Laight@ACULAB.COM \
    --cc=boqun.feng@gmail.com \
    --cc=carlos@redhat.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=fw@deneb.enyo.de \
    --cc=hpa@zytor.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=posk@posk.io \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox