linux-kernel - Re: [PATCH V3 1/4] Sched: Scheduler time slice extension

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <E47F0700-73FE-4D85-A5FA-CE14D0C41CE4@oracle.com>
Date: Tue, 6 May 2025 01:23:55 +0000
From: Prakash Sangappa <prakash.sangappa@...cle.com>
To: Steven Rostedt <rostedt@...dmis.org>
CC: Peter Zijlstra <peterz@...radead.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        "mathieu.desnoyers@...icios.com"
	<mathieu.desnoyers@...icios.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "bigeasy@...utronix.de" <bigeasy@...utronix.de>,
        "kprateek.nayak@....com"
	<kprateek.nayak@....com>
Subject: Re: [PATCH V3 1/4] Sched: Scheduler time slice extension



> On May 5, 2025, at 9:34 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> On Mon, 5 May 2025 15:58:12 +0000
> Prakash Sangappa <prakash.sangappa@...cle.com> wrote:
> 
>> Yes the application would only call they system call to yield cpu, if the extension is granted. 
>> 
>> The ‘RSEQ_CS_FLAG_DELAY_RESCHED’ bit in the ‘rseq’ structure  is cleared when the 
>> time extension is granted. This would indicate to the application that a time extension was
>> granted. The application is expected to call the system call if this bit got cleared.
>> 
>> However, It is possible that the thread gets rescheduled within the extended time window due 
>> to another wakeup or runtime expiry, which the user thread would not know unless we add
>> another bit to indicate it got rescheduled in the extended time. Also, if the task’s critical section
>> ran longer and the hrtick rescheduled the thread, the application would not know.
>> 
>> Or we need to guarantee the thread will not get rescheduled in the extended time?
>> 
>> I believe it would be same with your patch also.
> 
> So, my patch had a bit that got set when an extension happened.
> 
> Bit zero was set by the kernel.
> 
> Bits 1-31 was a counter (so that the code could nest).
> 
> On exiting the critical section a task would call something like:
> 
> static inline bool dec_extend(volatile unsigned *ptr)
> {
> if (*ptr & ~1)
> asm volatile("subl %b1,%0"
> : "+m" (*(volatile char *)ptr)
> : "iq" (0x2)
> : "memory");
> 
> return *ptr == 1;
> }
> 
> [..]
> if (dec_extend(&rseq_map->cr_counter)) {
> rseq_map->cr_counter = 0;
> yield();
> }
> 
> That is, the user space task would increment the counter by two when
> entering a critical section and decrement it by two when exiting. If the
> counter ends up as 1, then it not only is out of all nested critical
> sections, it also knows it was extended and will schedule out.
> 
> My kernel patches would set the bit if it extended the time slice, but if
> it then scheduled the task, it would clear it again. That way when the task
> is scheduled back on the CPU it will not call yield() again.
> 

I see, you set the flag in ‘rseq’ struct when extension was granted and clear it in 
rseq_delay_resched_tick(). In your case you had rseq_delay_resched_tick()
being called from hrtick_clear(). hrtick_clear() gets called from __schedule() if sched_feat()
is set.

In my patchset, it just clears the RSEQ_CS_FLAG_DELAY_RESCHED bit to indicate 
when extension was granted.

In order to allow the application to call sched_yield() to yield the cpu, only if the thread was not 
already rescheduled in the extended time, we would need the support as you have in your patch set.

Does it have to be sched_yield()? Or can the application call some other (fast)system call to yield the cpu
(getppid(2) ) if extended time was granted? 

It appears by default sched feature HRTICK/HRTICK_DL is disabled so hrtick_clear()
Will not get called from __schedule().  I have noticed that enabling these sched
feature to let hrtick_clear() get called from __schedule(), adds overhead.

So not sure if we need to enable the sched_feat(HRTICK//HRTICK_DL) to use the scheduler time extension.

Maybe rseq_delay_resched_tick() with this support,  would have to be called in __schedule() path but not 
thru hrtick_clear(),

-Prakash



> -- Steve