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

Ingo Molnar
2009-12-18T17:13:23Z

* Avi Kivity <avi@redhat.com> wrote:

> On 12/18/2009 07:17 AM, Ingo Molnar wrote:
> >
> >>It is not about naming. The accessors hide the locking mechanism for
> >>mmap_sem. Then you can change the locking in a central place.
> >>
> >>The locking may even become configurable later. Maybe an embedded solution
> >>will want the existing scheme but dual quad socket may want a distributed
> >>reference counter to avoid bouncing cachelines on faults.
> >Hiding the locking is pretty much the worst design decision one can make.
> >
>
> It does allow incremental updates. For example if we go with range locks,
> the accessor turns into a range lock of the entire address space; users can
> be converted one by one to use their true ranges in order of importance.

This has been brought up in favor of say the mmap_sem wrappers in the past
(but also mentioned for other wrappers), but the supposed advantage never
materialized.

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.

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.

Ingo