Received-SPF: pass (google.com: domain of linux-kernel+bounces-8823-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20231220001856.3710363-1-jstultz@google.com> <2b4bb9ce-fe92-47fe-9185-e29571502ae9@arm.com>
In-Reply-To: <2b4bb9ce-fe92-47fe-9185-e29571502ae9@arm.com>
From: John Stultz <jstultz@google.com>
Date: Thu, 21 Dec 2023 09:13:42 -0800
Message-ID: <CANDhNCrHd+5twWVNqBAhVLfhMhkiO0KjxXBmwVgaCD4kAyFyWw@mail.gmail.com>
Subject: Re: [PATCH v7 00/23] Proxy Execution: A generalized form of Priority
 Inheritance v7
To: Metin Kaya <metin.kaya@arm.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Joel Fernandes <joelaf@google.com>, 
	Qais Yousef <qyousef@google.com>, Ingo Molnar <mingo@redhat.com>, 
	Peter Zijlstra <peterz@infradead.org>, Juri Lelli <juri.lelli@redhat.com>, 
	Vincent Guittot <vincent.guittot@linaro.org>, Dietmar Eggemann <dietmar.eggemann@arm.com>, 
	Valentin Schneider <vschneid@redhat.com>, Steven Rostedt <rostedt@goodmis.org>, 
	Ben Segall <bsegall@google.com>, Zimuzo Ezeozue <zezeozue@google.com>, 
	Youssef Esmat <youssefesmat@google.com>, Mel Gorman <mgorman@suse.de>, 
	Daniel Bristot de Oliveira <bristot@redhat.com>, Will Deacon <will@kernel.org>, Waiman Long <longman@redhat.com>, 
	Boqun Feng <boqun.feng@gmail.com>, "Paul E. McKenney" <paulmck@kernel.org>, 
	Xuewen Yan <xuewen.yan94@gmail.com>, K Prateek Nayak <kprateek.nayak@amd.com>, 
	Thomas Gleixner <tglx@linutronix.de>, kernel-team@android.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 21, 2023 at 12:35=E2=80=AFAM Metin Kaya <metin.kaya@arm.com> wr=
ote:
> On 20/12/2023 12:18 am, John Stultz wrote:
> >
> > As Connor outlined in a previous submission of this patch series,
>
> Nit: Better to have a reference to Connor's patch series (i.e.,
> https://lore.kernel.org/lkml/20221003214501.2050087-1-connoro@google.com/=
)
> here?

Yes, thank you for providing the link!


> > * As discussed at OSPM[5], I like to split pick_next_task() up
> >    into two phases selecting and setting the next tasks, as
> >    currently pick_next_task() assumes the returned task will be
> >    run which results in various side-effects in sched class logic
> >    when it=E2=80=99s run. I tried to take a pass at this earlier, but
> >    it=E2=80=99s hairy and lower on the priority list for now.
>
> Do you think we should mention virtual runqueue idea and adding trace
> points to measure task migration times? They are not "open issues", but
> kind of to-do items in the agenda.
>

I appreciate you bringing those up. The virtual runqueue idea is still
a bit handwavy, but the trace points are a good item for the TODO.
Apologies for missing it, as you suggested it just the other day as I
was prepping these patches, and I didn't go back to add it here in the
cover letter.

thanks
-john