From: Andrea Arcangeli <andrea@e-mind.com>
To: Zlatko Calusic <Zlatko.Calusic@CARNet.hr>,
"Stephen C. Tweedie" <sct@redhat.com>,
Linus Torvalds <torvalds@transmeta.com>
Cc: Linux-MM List <linux-mm@kvack.org>,
Linux Kernel List <linux-kernel@vger.rutgers.edu>
Subject: Re: Removing swap lockmap...
Date: Mon, 18 Jan 1999 21:26:05 +0100 (CET) [thread overview]
Message-ID: <Pine.LNX.3.96.990118203741.9904A-100000@laser.bogus> (raw)
In-Reply-To: <87iue47gy4.fsf@atlas.CARNet.hr>
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
---------- -------------
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
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
next prev parent reply other threads:[~1999-01-18 20:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-01-18 15:12 Removing swap lockmap Zlatko Calusic
1999-01-18 20:26 ` Andrea Arcangeli [this message]
1999-01-18 22:24 ` BUG: deadlock in swap lockmap handling Alan Cox
1999-01-18 21:46 ` Removing swap lockmap Stephen C. Tweedie
1999-01-19 1:33 ` Zlatko Calusic
1999-01-19 0:34 ` Eric W. Biederman
1999-01-19 1:37 ` Zlatko Calusic
1999-01-19 18:15 ` Andrea Arcangeli
1999-01-20 17:09 ` Stephen C. Tweedie
1999-01-20 18:14 ` Zlatko Calusic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.3.96.990118203741.9904A-100000@laser.bogus \
--to=andrea@e-mind.com \
--cc=Zlatko.Calusic@CARNet.hr \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=sct@redhat.com \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.