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

From: Khalid Aziz
Date: Wed Mar 05 2014 - 19:18:40 EST


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