Re: [DOCUMENTATION] Revised Unreliable Kernel Locking Guide

[Paul E. McKenney]

On Fri, Dec 12, 2003 at 04:24:18PM +1100, Rusty Russell wrote:
> OK, I've put the html version up for your reading pleasure: the diff
> is quite extensive and hard to read.
> 
> http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/
> 
> Feedback welcome,
> Rusty.
> --
>   Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Hello, Rusty,

Good stuff!  A few comments, as always!

						Thanx, Paul

Glossary:

o	Hardware Interrupt / Hardware IRQ: How does in_irq()
	know that interrupts have been blocked?  The local_irq_disable()
	does not seem to mess with the counter, and preempt_disable()
	just does the standard inc/dec stuff...

	o	in_irq() is hardirq_count().
	o	hardirq_count() is (preempt_count() & HARDIRQ_MASK).
	o	preempt_count is an integer, HARDIRQ_MASK is a constant that
		is out of the normal inc/dec range.

	I see how an interrupt handler causes in_irq() to do its thing
	via the irq_enter() and irq_exit() macros, but I don't see how
	masking interrupts makes this happen.

	Probably just my confusion, but...

	Ditto for "in_interrupt()".  That would be for both the
	analysis and the probable confusion on my part.

o	Software Interrupt / softirq: formatting botch "of'software".
	This would be "o'software", right?

o	Preemption: Would it be worth changing the first bit
	of the second sentence to read something like: "In 2.5.4
	and later, when CONFIG_PREEMPT is set, this changes:"?

Overzealous Prevention Of Deadlocks:  Cute!!!

Avoiding Locks: Read Copy Update

o	Might be worth noting explicitly early on that updaters are
	running concurrently with readers.  Should be obvious given
	that the readers aren't doing any explicit synchronization,
	but I have run into confusion on this point surprisingly often.

o	Please add a note to the list_for_each_entry_rcu() description
	saying that writers (who hold appropriate locks) need not use
	the _rcu() variant.

o	Don't understand the blank line before and after the
	"struct rcu_head rcu;", but clearly doesn't affect
	functionality.  ;-)

o	If nothing blocks between the call to __cache_find() and the
	eventual object_put(), it is worthwhile to avoid the
	reference-count manipulation.  This would make all of
	cache_find() be almost as fast as UP, rather than just
	__cache_find().
-
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/