[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87wn0r6id9.fsf@oldenburg.str.redhat.com>
Date: Mon, 29 May 2023 21:35:30 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
"Paul E . McKenney" <paulmck@...nel.org>,
Boqun Feng <boqun.feng@...il.com>,
"H . Peter Anvin" <hpa@...or.com>, Paul Turner <pjt@...gle.com>,
linux-api@...r.kernel.org, Christian Brauner <brauner@...nel.org>,
David.Laight@...LAB.COM, carlos@...hat.com,
Peter Oskolkov <posk@...k.io>,
Alexander Mikhalitsyn <alexander@...alicyn.com>,
Chris Kennelly <ckennelly@...gle.com>,
Ingo Molnar <mingo@...hat.com>,
Darren Hart <dvhart@...radead.org>,
Davidlohr Bueso <dave@...olabs.net>,
André Almeida <andrealmeid@...lia.com>,
libc-alpha@...rceware.org, Steven Rostedt <rostedt@...dmis.org>,
Jonathan Corbet <corbet@....net>,
Noah Goldstein <goldstein.w.n@...il.com>,
Daniel Colascione <dancol@...gle.com>, longman@...hat.com
Subject: Re: [RFC PATCH v2 1/4] rseq: Add sched_state field to struct rseq
* Mathieu Desnoyers:
> +/*
> + * rseq_sched_state should be aligned on the cache line size.
> + */
> +struct rseq_sched_state {
> + /*
> + * Version of this structure. Populated by the kernel, read by
> + * user-space.
> + */
> + __u32 version;
> + /*
> + * The state is updated by the kernel. Read by user-space with
> + * single-copy atomicity semantics. This field can be read by any
> + * userspace thread. Aligned on 32-bit. Contains a bitmask of enum
> + * rseq_sched_state_flags. This field is provided as a hint by the
> + * scheduler, and requires that the page holding this state is
> + * faulted-in for the state update to be performed by the scheduler.
> + */
> + __u32 state;
> + /*
> + * Thread ID associated with the thread registering this structure.
> + * Initialized by user-space before registration.
> + */
> + __u32 tid;
> +};
How does the version handshake protocol in practice? Given that this
user-allocated?
I don't see why we can't stick this directly into struct rseq because
it's all public anyway.
The TID field would be useful in its own right.
Thanks,
Florian
Powered by blists - more mailing lists