Messages in this thread | | | Date | Fri, 18 Dec 2009 19:45:04 +0100 | From | Ingo Molnar <> | Subject | Re: [mm][RFC][PATCH 0/11] mm accessor updates. |
| |
* Christoph Lameter <cl@linux-foundation.org> wrote:
> > 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.
You need to loo at the patches. This is simply a step backwards:
- up_read(&mm->mmap_sem); + mm_read_unlock(mm);
because it hides the lock instance.
( You brought up -rt but that example does not apply: it doesnt 'hide' the lock instance in any way, it simply changes the preemption model. It goes to great lengths to keep existing locking patterns and does not obfuscate locking. )
Ingo
| |