From: Ed L Cashin <ecashin@uga.edu>
To: Kanoj Sarcar <kanojsarcar@yahoo.com>
Cc: Robert Love <rml@ximian.com>, linux-mm@kvack.org
Subject: Re: Documentation/vm/locking: why not hold two PT locks?
Date: Mon, 09 Feb 2004 11:19:09 -0500 [thread overview]
Message-ID: <87r7x4ns3m.fsf@cs.uga.edu> (raw)
In-Reply-To: <20040209074409.32804.qmail@web14306.mail.yahoo.com> (Kanoj Sarcar's message of "Sun, 8 Feb 2004 23:44:09 -0800 (PST)")
Kanoj Sarcar <kanojsarcar@yahoo.com> writes:
...
> Its been a while since I wrote up those rules in
> the "locking" file, but the example that Robert has
> pointed out involving two different threads, each
> crabbing one mm lock and trying for the next one,
> is the deadlock I had in mind. There may have been
> new changes in 2.5 timeframe that also requires
> the rule, I am not sure.
Thanks, Kanoj!
After further looking into it, one thing in Documentation/vm/locking
does seem out of date. It says that "Page stealers hold kernel_lock
to protect against a bunch of races."
The only page stealing code that I can find is in rmap.c and vmscan.c.
When vmscan.c:shrink_caches and its callees need to unmap a page,
rmap.c:try_to_unmap gets called. But nowhere is there a lock_kernel
call that I could find. Instead, they use trylocks and get the page
table lock before stealing a page.
Are there other page stealers?
--
--Ed L Cashin PGP public key: http://noserose.net/e/pgp/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2004-02-09 16:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-08 21:18 Ed L Cashin
2004-02-08 21:29 ` Robert Love
2004-02-08 21:47 ` Ed L Cashin
2004-02-08 22:12 ` Robert Love
2004-02-09 7:44 ` Kanoj Sarcar
2004-02-09 16:19 ` Ed L Cashin [this message]
2004-02-09 18:20 ` Kanoj Sarcar
2004-02-09 21:17 ` Ed L Cashin
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=87r7x4ns3m.fsf@cs.uga.edu \
--to=ecashin@uga.edu \
--cc=kanojsarcar@yahoo.com \
--cc=linux-mm@kvack.org \
--cc=rml@ximian.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox