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
| ||
|
Message-ID: <5317BE94.20703@oracle.com> Date: Wed, 05 Mar 2014 17:17:24 -0700 From: Khalid Aziz <khalid.aziz@...cle.com> To: David Lang <david@...g.hm> 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 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? Thanks, Khalid -- 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/
Powered by blists - more mailing lists