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  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]
Date:	Wed, 05 Mar 2014 18:22:12 -0700
From:	Khalid Aziz <>
To:	David Lang <>
CC:	Oleg Nesterov <>, Andi Kleen <>,
	Thomas Gleixner <>,
	One Thousand Gnomes <>,
	"H. Peter Anvin" <>, Ingo Molnar <>,,,,
Subject: Re: [RFC] [PATCH] Pre-emption control for userspace

On 03/05/2014 05:36 PM, David Lang wrote:
> Yes, you pay for two context switches, but you don't pay for threads
> B..ZZZ all running (and potentially spinning) trying to aquire the lock
> before thread A is able to complete it's work.

Ah, great. We are converging now.

> As soon as a second thread hits the contention, thread A gets time to
> finish.

Only as long as thread A could be scheduled immediately which may or may 
not be the case depending upon what else is running on the core thread A 
last ran on and if thread A needs to be migrated to another core.

> It's not as 'good' [1] as thread A just working longer,

and that is the exact spot where I am trying to improve performance.

> but it's FAR
> better than thread A sleeping while every other thread runs and
> potentially tries to get the lock

Absolutely. I agree with that.

> [1] it wastes the context switches, but it avoids the overhead of
> figuring out if the thread needs to extend it's time, and if it's time
> was actually extended, and what penalty it should suffer the next time
> it runs....

All of it can be done by setting and checking couple of flags in 
task_struct. That is not insignificant, but hardly expensive. Logic is 
quite simple:

	if (immmunity) {
		if (!penalty) {
			immunity = 0;
			penalty = 1;
			-- skip context switch --
		else {
			immunity = penalty = 0;
			-- do the context switch --

	penalty = 0;

This simple logic will also work to defeat the obnoxius threads that 
keep setting immunity request flag repeatedly within the same critical 
section to give themselves multiple extensions.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists