[lkml]   [1999]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: Removing swap lockmap...
On 18 Jan 1999, Zlatko Calusic wrote:

> 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
---------- -------------
...if (test_and_set_bit(lockmap))
... run_task_queue()
... clear_bit(lockmap)
.... wakeup(&lock_queue)
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
diff -u -r1.1.2.1 page_io.c
--- page_io.c 1999/01/18 01:32:53
+++ 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)) {
- 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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:49    [from the cache]
©2003-2011 Jasper Spaans