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 17:17:24 -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 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:

		if (!TRY_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?

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