Messages in this thread |  | | | Date | Tue, 8 Jun 2004 09:31:11 -0700 | | From | Andrew Morton <> | | Subject | Re: downgrade_write replacement in remap_file_pages |
| |
Andrea Arcangeli <andrea@suse.de> wrote: > > Apparently downgrade_write deadlocks the kernel in the mmap_sem > under load. I suspect some rwsem bug. Anyways it's matter of time before > in my tree I replace the rwsem implementation with my spinlock based > common code implementation again that I can understand trivially (unlike > the current code). I don't mind a microoptimization when the code is so > complicated, so I don't mind too much to fix whatever current bug in > downgrade_write.
I must say I agree with the sentiments - the current implementation doesn't have a very attractive complexity/benefit ratio. But I wrote a spinlock-based version three years ago too, so I'm biased ;) Certainly it is bog-simple and fixes up the overflow-at-32768-waiters bug.
I think a spinlock-based implementation would be OK if it was x86-specific, because x86 spin_unlock is cheap. But some architectures do atomic ops in spin_unlock and won't like it. Plus those architectures which can implement atomic_add_return() can implement nice versions of rwsems such as the ppc64 code. Although ppc64 still seems to have an overflow bug.
So ho-hum. As a first step, David, could you please take a look into what's up with downgrade_write()?
(Then again, we need to have a serious think about the overflow bug. It's fatal. Should we fix it? If so, the current rwsem implementation is probably unsalvageable). - 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/
|  |