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: <20250211082138.iqvedSfG@linutronix.de>
Date: Tue, 11 Feb 2025 09:21:38 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Joel Fernandes <joel@...lfernandes.org>,
	Prakash Sangappa <prakash.sangappa@...cle.com>,
	Peter Zijlstra <peterz@...radead.org>, linux-kernel@...r.kernel.org,
	linux-trace-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Ankur Arora <ankur.a.arora@...cle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>, linux-mm@...ck.org,
	x86@...nel.org, Andrew Morton <akpm@...ux-foundation.org>,
	luto@...nel.org, bp@...en8.de, dave.hansen@...ux.intel.com,
	hpa@...or.com, juri.lelli@...hat.com, vincent.guittot@...aro.org,
	willy@...radead.org, mgorman@...e.de, jon.grimm@....com,
	bharata@....com, raghavendra.kt@....com,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Konrad Wilk <konrad.wilk@...cle.com>, jgross@...e.com,
	Andrew.Cooper3@...rix.com, Vineeth Pillai <vineethrp@...gle.com>,
	Suleiman Souhlal <suleiman@...gle.com>,
	Ingo Molnar <mingo@...nel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Clark Williams <clark.williams@...il.com>, daniel.wagner@...e.com,
	Joseph Salisbury <joseph.salisbury@...cle.com>, broonie@...il.com
Subject: Re: [RFC][PATCH 1/2] sched: Extended scheduler time slice

On 2025-02-10 14:43:21 [-0500], Steven Rostedt wrote:
> On Thu, 6 Feb 2025 14:44:08 +0100
> Sebastian Andrzej Siewior <bigeasy@...utronix.de> wrote:
> 
> > I did add a scheduling point in rt_spin_unlock() if LAZY was set and
> > based on few tests it was something between noise and worse. It seems
> > that "run to completion" is better than interrupt the kernel in the
> > middle whatever it is doing. "Don't preempt the lock owner" is already
> > handled by LAZY with the scheduling point on return to userland.
> 
> Does that mean that PREEMPT_RT requires a non preempt method for
> SCHED_OTHER for SCHED_OTHER to not hit the issues that we were originally
> hitting? That is, with being able to preempt spin_locks in PREEMPT_RT,
> running a system with PREEMPT_RT in full preemption mode will still suffer
> performance issues against a non PREEMPT_RT running in full preemption mode?

So with LAZY_PREEMPT (not that one that was merged upstream, its
predecessor) we had a counter similar to the preemption counter. On each
rt_spin_lock() the counter was incremented, on each rt_spin_unlock() the
counter was decremented. Once the counter hit zero and the lazy preempt
flag was set (which was only set on schedule requests by SCHED_OTHER
tasks), we scheduled.
This improved the performance as we didn't schedule() while holding a
spinlock_t and then bump into the same lock in the next task.

We don't follow this behaviour exactly today.

Adding this behaviour back vs the behaviour we have now, doesn't seem to
improve anything at visible levels. We don't have a counter but we can
look at the RCU nesting counter which should be zero once locks have
been dropped. So this can be used for testing.

But as I said: using "run to completion" and preempt on the return
userland rather than once the lazy flag is seen and all locks have been
released appears to be better.

It is (now) possible that you run for a long time and get preempted
while holding a spinlock_t. It is however more likely that you release
all locks and get preempted while returning to userland.

> -- Steve

Sebastian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ