[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aBCZBhw4De6bv47_@jlelli-thinkpadt14gen4.remote.csb>
Date: Tue, 29 Apr 2025 11:16:54 +0200
From: Juri Lelli <juri.lelli@...hat.com>
To: John Stultz <jstultz@...gle.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Joel Fernandes <joelagnelf@...dia.com>,
Qais Yousef <qyousef@...alina.io>, Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Valentin Schneider <vschneid@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>,
Zimuzo Ezeozue <zezeozue@...gle.com>, Mel Gorman <mgorman@...e.de>,
Will Deacon <will@...nel.org>, Waiman Long <longman@...hat.com>,
Boqun Feng <boqun.feng@...il.com>,
"Paul E. McKenney" <paulmck@...nel.org>,
Metin Kaya <Metin.Kaya@....com>,
Xuewen Yan <xuewen.yan94@...il.com>,
K Prateek Nayak <kprateek.nayak@....com>,
Thomas Gleixner <tglx@...utronix.de>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Suleiman Souhlal <suleiman@...gle.com>, kernel-team@...roid.com
Subject: Re: [PATCH v16 1/7] sched: Add CONFIG_SCHED_PROXY_EXEC & boot
argument to enable/disable
On 16/04/25 14:24, John Stultz wrote:
> On Mon, Apr 14, 2025 at 1:50 AM Juri Lelli <juri.lelli@...hat.com> wrote:
> > On 11/04/25 23:02, John Stultz wrote:
> > > Add a CONFIG_SCHED_PROXY_EXEC option, along with a boot argument
> > > sched_proxy_exec= that can be used to disable the feature at boot
> > > time if CONFIG_SCHED_PROXY_EXEC was enabled.
> > >
> > > Cc: Joel Fernandes <joelagnelf@...dia.com>
> > > Cc: Qais Yousef <qyousef@...alina.io>
> > > Cc: Ingo Molnar <mingo@...hat.com>
> > > Cc: Peter Zijlstra <peterz@...radead.org>
> > > Cc: Juri Lelli <juri.lelli@...hat.com>
> > > Cc: Vincent Guittot <vincent.guittot@...aro.org>
> > > Cc: Dietmar Eggemann <dietmar.eggemann@....com>
> > > Cc: Valentin Schneider <vschneid@...hat.com>
> > > Cc: Steven Rostedt <rostedt@...dmis.org>
> > > Cc: Ben Segall <bsegall@...gle.com>
> > > Cc: Zimuzo Ezeozue <zezeozue@...gle.com>
> > > Cc: Mel Gorman <mgorman@...e.de>
> > > Cc: Will Deacon <will@...nel.org>
> > > Cc: Waiman Long <longman@...hat.com>
> > > Cc: Boqun Feng <boqun.feng@...il.com>
> > > Cc: "Paul E. McKenney" <paulmck@...nel.org>
> > > Cc: Metin Kaya <Metin.Kaya@....com>
> > > Cc: Xuewen Yan <xuewen.yan94@...il.com>
> > > Cc: K Prateek Nayak <kprateek.nayak@....com>
> > > Cc: Thomas Gleixner <tglx@...utronix.de>
> > > Cc: Daniel Lezcano <daniel.lezcano@...aro.org>
> > > Cc: Suleiman Souhlal <suleiman@...gle.com>
> > > Cc: kernel-team@...roid.com
> > > Tested-by: K Prateek Nayak <kprateek.nayak@....com>
> > > Signed-off-by: John Stultz <jstultz@...gle.com>
> > > ---
> >
> > ...
> >
> > > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> > > index 47972f34ea701..154f0aa0c6322 100644
> > > --- a/kernel/sched/sched.h
> > > +++ b/kernel/sched/sched.h
> > > @@ -1149,10 +1149,15 @@ struct rq {
> > > */
> > > unsigned int nr_uninterruptible;
> > >
> > > +#ifdef CONFIG_SCHED_PROXY_EXEC
> > > + struct task_struct __rcu *donor; /* Scheduling context */
> > > + struct task_struct __rcu *curr; /* Execution context */
> > > +#else
> > > union {
> > > struct task_struct __rcu *donor; /* Scheduler context */
> > > struct task_struct __rcu *curr; /* Execution context */
> > > };
> > > +#endif
> > > struct sched_dl_entity *dl_server;
> > > struct task_struct *idle;
> > > struct task_struct *stop;
> > > @@ -1347,10 +1352,17 @@ DECLARE_PER_CPU_SHARED_ALIGNED(struct rq, runqueues);
> > > #define cpu_curr(cpu) (cpu_rq(cpu)->curr)
> > > #define raw_rq() raw_cpu_ptr(&runqueues)
> > >
> > > +#ifdef CONFIG_SCHED_PROXY_EXEC
> > > +static inline void rq_set_donor(struct rq *rq, struct task_struct *t)
> > > +{
> > > + rcu_assign_pointer(rq->donor, t);
> > > +}
> > > +#else
> > > static inline void rq_set_donor(struct rq *rq, struct task_struct *t)
> > > {
> > > /* Do nothing */
> > > }
> > > +#endif
> >
> > Does this chunk belong here?
>
> Uhm. It's there intentionally (as with the config option we actually
> have the potential for the two contexts to be different), but I'm open
> to move it elsewhere if you think it sticks out oddly here and would
> fit better in a later change.
>
> Maybe, would adding a note in the commit message to clarify that this
> patch also adds the ability for the donor and curr contexts to be
> different, help?
Guess it might, yes. But, it's a nitpick anyway, so feel free to ignore.
:)
Thanks!
Juri
Powered by blists - more mailing lists