Messages in this thread | | | Date | Sat, 19 Dec 2009 08:18:33 +0900 (JST) | Subject | Re: [mm][RFC][PATCH 0/11] mm accessor updates. | From | "KAMEZAWA Hiroyuki" <> |
| |
Ingo Molnar wrote: > > * 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. > After rewriting speculative-page-fault patches, I feel I can do it without mm_accessor, by just skipping mmap_sem in fault.c. Then, original problem I tried to fix, false sharing at multithread page fault, can be fixed without this.
Then, I myself stop this.
About range-locking of mm_struct, I don't find any good approach.
Sorry for annoying and thank you all. -Kame
| |