> I removed swap lockmap all together and, to my surprise, I can't
> produce any ill behaviour on my system, not even under very heavy
> swapping (in low memory condition).
Looking at your patch (and so looking at the swap_lockmap code) I found a
potential deadlock in the current swap_lockmap handling:
task A task B
---------- -------------
rw_swap_page_base()
...if (test_and_set_bit(lockmap))
... run_task_queue()
swap_after_unlock_page()
... clear_bit(lockmap)
.... wakeup(&lock_queue)
...sleep_on(&lock_queue);
deadlocked
I think it will not harm too much because the window is not too big (but
not small) and because usually one of the process not yet deadlocked will
generate IO and will wakeup also the deadlocked process at I/O
completation time. A very lazy ;) but at the same time obviosly right
(that should not harm performances at all) fix could be to replace the
sleep_on() with a sleep_on_timeout(..., 1).
Index: page_io.c
===================================================================
RCS file: /var/cvs/linux/mm/page_io.c,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 page_io.c
--- page_io.c 1999/01/18 01:32:53 1.1.2.1
+++ linux/mm/page_io.c 1999/01/18 20:21:41
@@ -88,7 +88,7 @@
/* Make sure we are the only process doing I/O with this swap page. */
while (test_and_set_bit(offset,p->swap_lockmap)) {
run_task_queue(&tq_disk);
- sleep_on(&lock_queue);
+ sleep_on_timeout(&lock_queue, 1);
}
/*
I think we need the swap_lockmap in the shm case because without swap
cache a swapin could happen at the same time of the swapout because
find_in_swap_cache() won't work there.
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/