[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <17F87304-7F42-4619-965C-D9771F167E08@oracle.com>
Date: Tue, 1 Jul 2025 19:04:12 +0000
From: Prakash Sangappa <prakash.sangappa@...cle.com>
To: K Prateek Nayak <kprateek.nayak@....com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"peterz@...radead.org" <peterz@...radead.org>,
"rostedt@...dmis.org"
<rostedt@...dmis.org>,
"mathieu.desnoyers@...icios.com"
<mathieu.desnoyers@...icios.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"bigeasy@...utronix.de" <bigeasy@...utronix.de>,
"vineethr@...ux.ibm.com"
<vineethr@...ux.ibm.com>
Subject: Re: [PATCH V6 0/7] Scheduler time slice extension
> On Jun 30, 2025, at 9:30 PM, K Prateek Nayak <kprateek.nayak@....com> wrote:
>
> Hello Prakash,
>
> On 7/1/2025 6:07 AM, Prakash Sangappa wrote:
>> Prakash Sangappa (7):
>> Sched: Scheduler time slice extension
>> Sched: Indicate if thread got rescheduled
>> Sched: Tunable to specify duration of time slice extension
>> Sched: Add scheduler stat for cpu time slice extension
>> Sched: Add tracepoint for sched time slice extension
>> Add API to query supported rseq cs flags
>> Introduce a config option for scheduler time slice extension feature
>
> nit.
>
> IMO, the ordering of these patches can be improved. Introduction of
> CONFIG_SCHED_PREEMPT_DELAY can come first followed by incrementally
> adding the scheduler bits, followed by "rseq: Add API to query supported
> rseq cs flags" and then finally introduce the bits that introduces
> "RSEQ_CS_FLAG_DELAY_RESCHED" and allows the user to set.
Ok, I can introduce the CONFIG_SCHED_PREEMPT_DELAY changes into patch 1 itself, instead of
It being a separate patch.
Thanks,
-Prakash.
>
> This way all the CONFIG_SCHED_PREEMPT_DELAY can live in one place and
> make it easier to review the entire series.
>
> --
> Thanks and Regards,
> Prateek
>
Powered by blists - more mailing lists