From: Andrew Morton <akpm@zip.com.au>
To: Daniel Phillips <phillips@arcor.de>
Cc: Christian Ehrhardt <ehrhardt@mathematik.uni-ulm.de>,
lkml <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: MM patches against 2.5.31
Date: Mon, 26 Aug 2002 14:31:57 -0700 [thread overview]
Message-ID: <3D6A9E4D.DBCC5D0A@zip.com.au> (raw)
In-Reply-To: <E17jQB8-0002Zi-00@starship>
Daniel Phillips wrote:
>
> ...
> > If you think about who is going to remove the page from the lru you'll
> > see the problem.
>
> Nope, still don't see it. Whoever hits put_page_testzero frees the page,
> secure in the knowlege that there are no other references to it.
Sure. But this requires that the caller of page_cache_release() has
previously removed the page from the LRU. We (used to) do that for truncate
and page reclaim. But we did not do that for anon pages.
For anon pages, we perform magical LRU removal when the page refcount
goes to zero.
The fact that we performed explicit removal in one place, and magical removal
in the other was unfortunate. I nuked the explicit removal and made it
all magical (explicit removal in truncate_complete_page() was wrong anyway - the
page could have been rescued and anonymised by concurrent pagefault and must
stay on the LRU).
Possibly, we could go back to explicit removal everywhere. Haven't
really looked at that, but I suspect we're back to a similar problem:
to do you unracily determine whether the page should be removed from
the LRU? Take ->page_table_lock and look at page_count(page)? Worried.
I like the magical-removal-just-before-free, and my gut feel is that
it'll provide a cleaner end result.
Making presence on the LRU contribute to page->count is attractive,
if only because it removes some irritating and expensive page_cache_gets
and puts from shrink_cache and refill_inactive. But for it to be useful,
we must perform explicit removal everywhere.
Making presence on the LRU contribute to page->count doesn't fundamentally
change anything of course - it offsets the current problems by one.
Then again, it would remove all page_cache_gets/releases from vmscan.c
and may thus make the race go away. That's a bit of a timebomb though.
--
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/
next prev parent reply other threads:[~2002-08-26 21:31 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-22 2:29 Andrew Morton
2002-08-22 11:28 ` Christian Ehrhardt
2002-08-26 1:52 ` Andrew Morton
2002-08-26 9:10 ` Christian Ehrhardt
2002-08-26 14:22 ` Daniel Phillips
2002-08-26 15:29 ` Christian Ehrhardt
2002-08-26 17:56 ` Daniel Phillips
2002-08-26 19:24 ` Andrew Morton
2002-08-26 19:34 ` Daniel Phillips
2002-08-26 19:48 ` Christian Ehrhardt
2002-08-27 9:22 ` Christian Ehrhardt
2002-08-27 19:19 ` Andrew Morton
2002-08-26 20:00 ` Christian Ehrhardt
2002-08-26 20:09 ` Daniel Phillips
2002-08-26 20:58 ` Christian Ehrhardt
2002-08-27 16:48 ` Daniel Phillips
2002-08-28 13:14 ` Christian Ehrhardt
2002-08-28 17:18 ` Daniel Phillips
2002-08-28 17:42 ` Andrew Morton
2002-08-28 20:41 ` Daniel Phillips
2002-08-28 21:03 ` Andrew Morton
2002-08-28 22:04 ` Daniel Phillips
2002-08-28 22:39 ` Andrew Morton
2002-08-28 22:57 ` Daniel Phillips
2002-08-26 21:31 ` Andrew Morton [this message]
2002-08-27 3:42 ` Benjamin LaHaise
2002-08-27 4:37 ` Andrew Morton
2002-08-22 15:59 ` Steven Cole
2002-08-22 16:06 ` Martin J. Bligh
2002-08-22 19:45 ` Steven Cole
2002-08-26 2:15 ` Andrew Morton
2002-08-26 2:08 ` Martin J. Bligh
2002-08-26 2:32 ` Andrew Morton
2002-08-26 3:06 ` Steven Cole
2002-08-26 22:09 Ed Tomlinson
2002-08-26 23:58 ` Andrew Morton
2002-08-27 0:13 ` Rik van Riel
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=3D6A9E4D.DBCC5D0A@zip.com.au \
--to=akpm@zip.com.au \
--cc=ehrhardt@mathematik.uni-ulm.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=phillips@arcor.de \
/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