Re: rwsem: down_read_unfair() proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Michel Lespinasse wrote:
On Wed, May 05, 2010 at 11:03:40AM +0100, David Howells wrote:
If the system is as heavily loaded as you say, how do you prevent
writer starvation?  Or do things just grind along until sufficient
threads are queued waiting for a write lock?

Reader/Writer fairness is not disabled in the general case - it only is
for a few specific readers such as /proc/<pid>/maps. In particular, the
do_page_fault path, which holds a read lock on mmap_sem for potentially long
(~disk latency) periods of times, still uses a fair down_read() call.
In comparison, the /proc/<pid>/maps path which we made unfair does not
normally hold the mmap_sem for very long (it does not end up hitting disk);
so it's been working out well for us in practice.


FWIW, these sorts of block-ups are usually really pronounce on machines with harddrives that take _forever_ to respond to SMART commands (which are done via PIO, and which can serialize many drives when they are hidden behind a port multiplier). We've seen cases where hard faults can take unusually long on an otherwise non-busy machines (~10 seconds?).

The other case we have problems with mmap_sem from a cluster monitoring perspective occurs when we get blocked up behind a task that is having problems dying from oom. We have a variety of hacks used internally to cover these cases, though I think we (David and I?) figured that it'd make more sense to fix the dependencies on down_read(&current->mmap_sem) in the do_exit() path. For instance, it really makes no sense to coredump when we are being oom killed (and thus we should be able to skip the mmap_sem dependency there..).

Mike Waychison

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]