Re: [mm][RFC][PATCH 0/11] mm accessor updates.

[Christoph Lameter]

On Fri, 18 Dec 2009, Ingo Molnar wrote:

> In reality updating the locking usage is never a big issue - it's almost
> mechanic and the compiler is our friend if we want to change semantics. Hiding
> the true nature and the true dependencies of the code, hiding the type of the
> lock is a bigger issue.

Which is exactly what the RT tree does with spinlocks by turning them into
mutexes. Spinlocks and the various derivates are very similar to what is
done here.

> We've been through this many times in the past within the kernel: many times
> when we hid some locking primitive within some clever wrapping scheme the
> quality of locking started to deteriorate. In most of the important cases we
> got rid of the indirection and went with an existing core kernel locking
> primitive which are all well known and have clear semantics and lead to more
> maintainable code.

The existing locking APIs are all hiding lock details at various levels.
We have various specific APIs for specialized locks already Page locking
etc.

How can we make progress on this if we cannot look at the mmap_sem
semantics in one place and then come up with viable replacements? mmap_sem
is used all over the place and having one place for the accessors allows
us to clarify lock semantics and tie loose things down. There are similar
RW semantics in various other places. This could result in another type of
RW lock that will ultimately allow us to move beyond the rw sem problems
of today.
--
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/