Messages in this thread |  | | Date | Thu, 20 Sep 2001 09:19:54 +0200 | From | Andrea Arcangeli <> | Subject | Re: Deadlock on the mm->mmap_sem |
| |
On Thu, Sep 20, 2001 at 08:05:57AM +0100, David Howells wrote: > > Andrea Arcangeli <andrea@suse.de> wrote: > > yes, one solution to the latency problem without writing the > > ugly code would be simply to add a per-process counter to pass to a > > modified rwsem api, then to hide the trickery in a mm_down_read macro. > > such way it will be recursive _and_ fair. > > You'd need a counter per-process per-mm_struct. Otherwise you couldn't do a > recursive read lock simultaneously in two or more different processes, and > also allow any one process to lock multiple mm_structs.
the process doesn't need to lock multiple mm_structs at the same time.
I mean, we just need to allow a single task to go through, doesn't matter if the other tasks/threads are stuck, they will wait the write to finish. that's exactly where the fairness cames from.
The only thing that matters is that if a certain task passes the first read lock of its mmstruct semaphore, it will also pass any other further recursive lock again of its own _same_ mmstruct. So a per-process recursor is all what we need.
Must not be per-mm, per-mm would work but it would simply introduce the unfairness again.
Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |