[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o7hmdnnv.ffs@tglx>
Date: Thu, 28 Sep 2023 22:54:12 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org,
"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>,
Florian Weimer <fw@...eb.enyo.de>, 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,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Florian Weimer <fweimer@...hat.com>
Subject: Re: [RFC PATCH v2 1/4] rseq: Add sched_state field to struct rseq
On Mon, May 29 2023 at 15:14, Mathieu Desnoyers wrote:
> +/*
> + * 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;
> +};
> +
> /*
> * struct rseq is aligned on 4 * 8 bytes to ensure it is always
> * contained within a single cache-line.
> @@ -148,6 +180,15 @@ struct rseq {
> */
> __u32 mm_cid;
>
> + __u32 padding1;
> +
> + /*
> + * Restartable sequences sched_state_ptr field. Initialized by
> + * userspace to the address at which the struct rseq_sched_state is
> + * located. Read by the kernel on rseq registration.
> + */
> + __u64 sched_state_ptr;
> +
Why is this a separate entity instead of being simply embedded into
struct rseq?
Neither the code comment nor the changelog tells anything about that.
If your intention was to provide a solution for process shared futexes
then you completely failed to understand how process shared futexes
work. If not, then please explain why you need a pointer and the
associated hackery to deal with it.
Thanks,
tglx
Powered by blists - more mailing lists