From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Cc: Rik van Riel <riel@redhat.com>,
akpm@linux-foundation.org, kosaki.motohiro@jp.fujitsu.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] take pageout refcount into account for remove_exclusive_swap_page
Date: Thu, 15 May 2008 13:55:24 -0400 [thread overview]
Message-ID: <1210874124.7389.51.camel@lts-notebook> (raw)
In-Reply-To: <482B9CCA.9060203@mxp.nes.nec.co.jp>
On Thu, 2008-05-15 at 11:15 +0900, Daisuke Nishimura wrote:
> On 2008/05/14 4:02 +0900, Lee Schermerhorn wrote:
> > On Tue, 2008-05-13 at 14:09 -0400, Rik van Riel wrote:
> >> On Tue, 13 May 2008 13:43:55 -0400
> >> Lee Schermerhorn <Lee.Schermerhorn@hp.com> wrote:
> >>
> >>> Or, more generally, 2 + N, for an anon page that is mapped [must be
> >>> read-only, right?] by N processes. This can happen after, e.g., fork().
> >>> Looks like this patch handles the condition just fine, but you might
> >>> want to reflect this in the comment.
> >> No, this patch only removes a page from the swap cache that is mapped
> >> by one process. The function page_mapped() returns either 1 or 0, not
> >> the same as page_mapcount().
> >
> > Duh! I was reading "page_mapcount()", 'cause that's what I've been
> > considering using for this purpose.
> >
> >>
> >> I am not sure if trying to handle swap cache pages that are mapped by
> >> multiple processes could get us into other corner cases and think that
> >> we should probably try to stick to the safe thing for now.
>
> I think it would be better to add a comment of
> remove_exclusive_swap_page_ref() that it doesn't handle
> swap caches that are mapped by multiple processes for safty.
>
> >
> > OK. I can test the more general case down the road.
> >
> >> Besides, shouldn't anonymous shared pages be COW and relatively rare?
> >
> > Well, all anon pages are shared right after fork(), right? They only
> > become private once they've been written to. I don't have a feel for
> > the relative numbers of shared anon vs COWed anon--either in general or
> > in the swap cache.
> >
> >>> Now, I think I can use this to try to remove anon pages from the swap
> >>> cache when they're mlocked.
> >
> > I suppose I can just go ahead and use this version with my stress load
> > and count the times when I could have freed the swap cache entry, but
> > didn't because it's mapped in multiple address spaces. Later ... :)
> >
>
> Lee, Rik's version looks good to me except mlocked case, but
> do you have any plan to handle these cases?
Well, it's really just an optimization--freeing swap cache entry, if
possible, when mlocking a page. I'll patch Rik's version to use
page_mapcount() and test heavily before proposing to do this. I suppose
we can also discuss whether we want a separate version that frees swap
mapped by multiple tasks for the mlock case, and keep Rik's version for
vmscan. However, I think that if it's safe in the mlock case, it should
be safe for vmscan. We'll see.
Lee
>
>
> >>>> + */
> >>>> +int remove_exclusive_swap_page_ref(struct page *page)
> >>>> +{
> >>>> + return remove_exclusive_swap_page_count(page, 2 + page_mapped(page));
> >>>> +}
> >>>> +
> >>>> +/*
> >>>> * Free the swap entry like above, but also try to
> >>>> * free the page cache entry if it is the last user.
> >>>> */
> >>>>
> >>>> All Rights Reversed
> >>
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
next prev parent reply other threads:[~2008-05-15 17:56 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-28 18:18 [PATCH -mm 00/15] VM pageout scalability improvements (V6) Rik van Riel
2008-04-28 18:18 ` [PATCH -mm 01/15] FYI: vmstats are "off-by-one" Rik van Riel
2008-04-28 18:18 ` [PATCH -mm 02/15] move isolate_lru_page() to vmscan.c Rik van Riel
2008-04-28 18:18 ` [PATCH -mm 03/15] Use an indexed array for LRU variables Rik van Riel
2008-04-28 18:18 ` [PATCH -mm 04/15] use an array for the LRU pagevecs Rik van Riel
2008-04-28 18:18 ` [PATCH -mm 05/15] free swap space on swap-in/activation Rik van Riel
2008-05-12 11:21 ` Daisuke Nishimura
2008-05-12 13:33 ` Rik van Riel
2008-05-13 13:00 ` Daisuke Nishimura
2008-05-13 13:11 ` Rik van Riel
2008-05-13 16:04 ` [PATCH] take pageout refcount into account for remove_exclusive_swap_page Rik van Riel
2008-05-13 17:43 ` Lee Schermerhorn
2008-05-13 18:09 ` Rik van Riel
2008-05-13 19:02 ` Lee Schermerhorn
2008-05-15 2:15 ` Daisuke Nishimura
2008-05-15 17:55 ` Lee Schermerhorn [this message]
[not found] ` <1210600296.7300.23.camel@lts-notebook>
2008-05-13 12:39 ` [PATCH -mm 05/15] free swap space on swap-in/activation Daisuke Nishimura
2008-04-28 18:18 ` [PATCH -mm 06/15] define page_file_cache() function Rik van Riel
2008-04-28 18:18 ` [PATCH -mm 07/15] split LRU lists into anon & file sets Rik van Riel
2008-05-10 7:50 ` MinChan Kim
2008-04-28 18:18 ` [PATCH -mm 08/15] SEQ replacement for anonymous pages Rik van Riel
2008-04-28 18:18 ` [PATCH -mm 09/15] add some sanity checks to get_scan_ratio Rik van Riel
2008-05-15 6:34 ` MinChan Kim
2008-05-15 13:12 ` Rik van Riel
2008-05-16 6:42 ` MinChan Kim
2008-05-16 16:47 ` Rik van Riel
2008-04-28 18:18 ` [PATCH -mm 10/15] add newly swapped in pages to the inactive list Rik van Riel
2008-04-28 18:18 ` [PATCH -mm 11/15] more aggressively use lumpy reclaim Rik van Riel
2008-04-28 18:18 ` [PATCH -mm 12/15] No Reclaim LRU Infrastructure Rik van Riel
2008-04-28 18:18 ` [PATCH -mm 13/15] Non-reclaimable page statistics Rik van Riel
2008-04-28 18:18 ` [PATCH -mm 14/15] ramfs pages are non-reclaimable Rik van Riel
2008-04-28 18:18 ` [PATCH -mm 15/15] SHM_LOCKED pages are nonreclaimable Rik van Riel
2008-04-28 19:55 ` [PATCH -mm 00/15] VM pageout scalability improvements (V6) Rik van Riel
2008-05-08 4:54 ` 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=1210874124.7389.51.camel@lts-notebook \
--to=lee.schermerhorn@hp.com \
--cc=akpm@linux-foundation.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nishimura@mxp.nes.nec.co.jp \
--cc=riel@redhat.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
Powered by JetHome