Re: [RFC PATCH] Fair low-latency rwlock v5

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Mathieu Desnoyers <mathieu.desnoyers@...>
Cc: Linus Torvalds <torvalds@...>, H. Peter Anvin <hpa@...>, Jeremy Fitzhardinge <jeremy@...>, Andrew Morton <akpm@...>, Ingo Molnar <mingo@...>, Joe Perches <joe@...>, <linux-kernel@...>
Date: Monday, August 18, 2008 - 7:25 pm

On Sun, Aug 17, 2008 at 03:10:35PM -0400, Mathieu Desnoyers wrote:

Interesting approach!  Questions and comments interspersed below.

						Thanx, Paul


OK...  64 bits less three for the writer bits is 61 bits, divided by
four gives us 15 bits, which limits us to 32,768 CPUs (16,384 if we need
a guard bit separating the fields).  This should be enough for the next
few years.

However, if critical sections are to be preemptable (as they need to be
in -rt, then this limit applies to the number of -tasks- rather than the
number of CPUs.  32,768 is IMHO an uncomfortably low ceiling for the
number of tasks in a system, given that my laptop supports several
thousand without breaking a sweat.

So, how about combining the softirq and hardirq bits, giving the range 0
.. 2*log_2(NR_CPUS)-1 over to tasks?  This would give 30 bits, allowing
more than 10^9 tasks, which should be enough for the next few years.
Better yet, why not begin the bit allotment at the high end of the word,
allowing whatever is left over at the bottom for tasks?

Alternatively, "hardirq" and "softirq" runs in process context in -rt,
so the three read-side bitfields should be able to be combined into one
in that case.


NR_CPUS is required to be a power of two?  News to me...


Suggest inlining this one, as it is just a wrapper.  (Or is gcc smart
enough to figure that out on its own these days?)


I don't understand the need for this smp_rmb() -- what other location
are we maintaining order with?  The CPU must maintain order of accesses
to a single variable (cache coherence requires this).

I suggest replacing the smp_rmb() with a barrier().  Not that optimizing
a spinloop is violently important...


Why not use fair_read_trylock_uncontended()?  Or equivalently, why not
replace calls to fair_read_trylock_uncontended() with the bare cmpxchg?


Suggest replacing the smp_rmb() with barrier() as noted above.


Suggest replacing the smp_rmb() with barrier() as noted above.


Why don't we use fair_write_subscribe() here?  Ah, because we have
already disabled preemption...

OK, so why do we have fair_write_subscribe() defined in the first place?


OK, I'll bite...  Why don't we also have to wait for the softirq and
hardirq readers?  I would expect THREAD_RMASK|SOFTIRQ_RMASK|HARDIRQ_RMASK
rather than just THREAD_RMASK above.

Never mind, I finally see the following pair of statements.

So, the idea is to allow recursive readers in irq when we also have
readers in the interrupted process context, right?  But isn't the
common case going to be no irq handlers read-holding the lock?  If
so, wouldn't we want to try for all of them at once if we could, using
a state machine?

Also, just to be sure I understand, writers waiting for other writers
would spin in the above _fair_write_lock_ctx_wait(), correct?


Why not just local_irq_disable() at this point and be done with it?


"justify"?  (Sorry, couldn't resist...)


Doesn't local_irq_disable() imply local_bh_disable()?  So why not just
do local_irq_disable()?


Seems like we would want to at least give an error if there were
hardirq readers...  (Can't think of a reasonable use case mixing
fair_write_lock_bh() with hardirq readers, but might well be simply a
momentary failure of imagination.)


The theory here is that there shouldn't be any readers in bh or irq?
But suppose that we are calling fair_write_lock() with irqs already
disabled?  Wouldn't we still want to wait for bh and irq readers in
that case?


I still find the _subscribed() stuff a bit scary...  Sample use case?

--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH] x86_64 : support atomic ops with 64 bits integer val..., Mathieu Desnoyers, (Sat Aug 16, 3:39 am)
Re: [PATCH] x86_64 : support atomic ops with 64 bits integer..., Mathieu Desnoyers, (Sat Aug 16, 11:43 am)
[RFC PATCH] Fair rwlock, Mathieu Desnoyers, (Sat Aug 16, 5:19 pm)
Re: [RFC PATCH] Fair rwlock, Linus Torvalds, (Sat Aug 16, 5:33 pm)
[RFC PATCH] Fair low-latency rwlock v3, Mathieu Desnoyers, (Sun Aug 17, 3:53 am)
Re: [RFC PATCH] Fair low-latency rwlock v3, Linus Torvalds, (Sun Aug 17, 12:17 pm)
[RFC PATCH] Fair low-latency rwlock v5, Mathieu Desnoyers, (Sun Aug 17, 3:10 pm)
Re: [RFC PATCH] Fair low-latency rwlock v5, Peter Zijlstra, (Mon Aug 25, 3:20 pm)
Re: [RFC PATCH] Fair low-latency rwlock v5, Paul E. McKenney, (Mon Aug 18, 7:25 pm)
Re: [RFC PATCH] Fair low-latency rwlock v5, Mathieu Desnoyers, (Tue Aug 19, 2:04 am)
Re: [RFC PATCH] Fair low-latency rwlock v5, Mathieu Desnoyers, (Tue Aug 19, 3:33 am)
Re: [RFC PATCH] Fair low-latency rwlock v5, Linus Torvalds, (Tue Aug 19, 12:48 pm)
[RFC PATCH] Writer-biased low-latency rwlock v8, Mathieu Desnoyers, (Thu Aug 21, 4:50 pm)
Re: [RFC PATCH] Writer-biased low-latency rwlock v8, Linus Torvalds, (Thu Aug 21, 5:00 pm)
Re: [RFC PATCH] Writer-biased low-latency rwlock v8, H. Peter Anvin, (Thu Aug 21, 5:26 pm)
Re: [RFC PATCH] Writer-biased low-latency rwlock v8, Linus Torvalds, (Thu Aug 21, 5:41 pm)
Re: [RFC PATCH] Writer-biased low-latency rwlock v8, Linus Torvalds, (Thu Aug 21, 5:15 pm)
Re: [RFC PATCH] Writer-biased low-latency rwlock v8, Mathieu Desnoyers, (Sat Aug 23, 1:09 am)
Re: [RFC PATCH] Writer-biased low-latency rwlock v8, Linus Torvalds, (Sat Aug 23, 2:02 pm)
Re: [RFC PATCH] Writer-biased low-latency rwlock v8, Mathieu Desnoyers, (Sat Aug 23, 4:30 pm)
Re: [RFC PATCH] Writer-biased low-latency rwlock v8, Linus Torvalds, (Sat Aug 23, 5:40 pm)
Re: [RFC PATCH] Writer-biased low-latency rwlock v8, Linus Torvalds, (Thu Aug 21, 6:22 pm)
Re: [RFC PATCH] Fair low-latency rwlock v5, Mathieu Desnoyers, (Tue Aug 19, 5:06 am)
Re: [RFC PATCH] Fair low-latency rwlock v5, Linus Torvalds, (Mon Aug 18, 2:59 pm)
Re: [RFC PATCH] Fair low-latency rwlock v5 (updated benchmar..., Mathieu Desnoyers, (Sun Aug 17, 5:30 pm)