linux-kernel - Re: [RFC] [PATCH] Pre-emption control for userspace

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: <alpine.DEB.2.02.1403051631590.6682@nftneq.ynat.uz>
Date:	Wed, 5 Mar 2014 16:36:18 -0800 (PST)
From:	David Lang <david@...g.hm>
To:	Khalid Aziz <khalid.aziz@...cle.com>
cc:	Oleg Nesterov <oleg@...hat.com>, Andi Kleen <andi@...stfloor.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
	peterz@...radead.org, akpm@...ux-foundation.org,
	viro@...iv.linux.org.uk, linux-kernel@...r.kernel.org
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 
lock

[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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/