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, 5 Mar 2014 16:36:18 -0800 (PST)
From:	David Lang <>
To:	Khalid Aziz <>
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 Wed, 5 Mar 2014, Khalid Aziz wrote:

> On 03/05/2014 04:59 PM, David Lang wrote:
>> what's the cost to setup mmap of this file in /proc. this is sounding
>> like a lot of work.
> That is a one time cost paid when a thread initializes itself.
>>>> is this gain from not giving up the CPU at all? or is it from avoiding
>>>> all the delays due to the contending thread trying in turn? the
>>>> yield_to() approach avoids all those other threads trying in turn so it
>>>> should get fairly close to the same benefits.
>>> The gain is from avoiding contention by giving locking thread a chance
>>> to complete its critical section which is expected to be very short
>>> (certainly shorter than timeslice). Pre-emption immunity gives it one
>>> and only one additional timeslice.
>> but the yield_to() does almost the same thing, there is a small bump,
>> but you don't have to wait for thread B to spin, thread C..ZZZ etc to
>> spin before thread A can finish it's work. As soon as the second thread
>> hits the critical section, thread A is going to be able to do more work
>> (and hopefully finish)
>>> Hope this helps clear things up.
>> It doesn't sound like you and I are understanding how the yield_to()
>> approach would work. I hope my comments have helped get us on the same
>> page.
> I apologize if I am being dense. My understanding of yield_to() is what Oleg 
> had said in his reply earlier, so I will quote the example he gave:
> 	my_lock()
> 	{
> 		if (!TRY_LOCK()) {
> 			yield_to(owner);
> 			LOCK();
> 		}
> 		owner = gettid();
> 	}
> If thread A had already lost the processor by the time thread B executes 
> above code, wouldn't we have paid the price of two context switches for 
> thread A?

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.

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

It's not as 'good' [1] as thread A just working longer, but it's FAR better than 
thread A sleeping while every other thread runs and potentially tries to get the 

[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....

I expect that in practice, it will be very close to the 'theoretical ideal' of 
"I'm doing something important, don't interrupt me", without all the potential 
abuse of such a flag.

David Lang
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