All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Rik van Riel <riel@redhat.com>
Subject: Re: [patch] mm: use-once mapped file pages
Date: Wed, 16 Sep 2009 21:04:31 +0200	[thread overview]
Message-ID: <20090916190431.GA20897@cmpxchg.org> (raw)
In-Reply-To: <28c262360909150826s2a0f5f0dpd111640f92d0f5ff@mail.gmail.com>

Hello Minchan,

On Wed, Sep 16, 2009 at 12:26:27AM +0900, Minchan Kim wrote:
> Hi, Hannes.

[snapped stuff Rik answered already]

> > When dropping into reclaim, the VM has a hard time making progress
> > with these pages dominating.  And since all mapped pages are treated
> > equally (i.e. anon pages as well), a major part of the anon working
> > set is swapped out before the hashing completes as well.
> >
> > Failing reclaim and swapping show up pretty quickly in decreasing
> > overall system interactivity, but also in the throughput of the
> > hashing process itself.
> >
> > This patch implements a use-once strategy for mapped file pages.
> >
> > For this purpose, mapped file pages with page table references are not
> > directly activated at the end of the inactive list anymore but marked
> > with PG_referenced and sent on another roundtrip on the inactive list.
> > If such a page comes in again, another page table reference activates
> > it while the lack thereof leads to its eviction.
> >
> > The deactivation path does not clear this mark so that a subsequent
> > page table reference for a page coming from the active list means
> > reactivation as well.
> 
> It seems to be good idea. but I have a concern about embedded.
> AFAIK, some CPUs don't have accessed bit by hardware.
> maybe ARM series.
> (Nowadays, Some kinds of CPU series just supports access bit.
> but there are still CPUs that doesn't support it)
> 
> I am not sure there are others architecture.
> Your idea makes mapped page reclaim depend on access bit more tightly.
>  :(

ARM seems to emulate the accessed bit by ensuring a subsequent access
will fault when the young bit is cleared, so we should get one extra
minor fault per finally activated mapped file page as a trade-off.

I am not too concerned about that because it should be a rather rare
event.  Only fresh pages go through that.  PG_referenced is remembered
over activation/deactivation and once it's set, a page is treated just
like it is now: activated if referenced, reclaimed if not.

So yeah, there is a bit more overhead for ARM to approximate the
working set initially.  But the results are more trustworthy and we
get rid of a badly performing corner case in the VM.

> > diff --git a/mm/rmap.c b/mm/rmap.c
> > index 28aafe2..0c88813 100644
> > --- a/mm/rmap.c
> > +++ b/mm/rmap.c
> > @@ -508,9 +508,6 @@ int page_referenced(struct page *page,
> >  {
> >        int referenced = 0;
> >
> > -       if (TestClearPageReferenced(page))
> > -               referenced++;
> > -

This hunk should also get removed from the !CONFIG_MMU dummy function.
I'll wait a bit for more feedback and send a fixed revision.

Thanks,
	Hannes

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Rik van Riel <riel@redhat.com>
Subject: Re: [patch] mm: use-once mapped file pages
Date: Wed, 16 Sep 2009 21:04:31 +0200	[thread overview]
Message-ID: <20090916190431.GA20897@cmpxchg.org> (raw)
In-Reply-To: <28c262360909150826s2a0f5f0dpd111640f92d0f5ff@mail.gmail.com>

Hello Minchan,

On Wed, Sep 16, 2009 at 12:26:27AM +0900, Minchan Kim wrote:
> Hi, Hannes.

[snapped stuff Rik answered already]

> > When dropping into reclaim, the VM has a hard time making progress
> > with these pages dominating. A And since all mapped pages are treated
> > equally (i.e. anon pages as well), a major part of the anon working
> > set is swapped out before the hashing completes as well.
> >
> > Failing reclaim and swapping show up pretty quickly in decreasing
> > overall system interactivity, but also in the throughput of the
> > hashing process itself.
> >
> > This patch implements a use-once strategy for mapped file pages.
> >
> > For this purpose, mapped file pages with page table references are not
> > directly activated at the end of the inactive list anymore but marked
> > with PG_referenced and sent on another roundtrip on the inactive list.
> > If such a page comes in again, another page table reference activates
> > it while the lack thereof leads to its eviction.
> >
> > The deactivation path does not clear this mark so that a subsequent
> > page table reference for a page coming from the active list means
> > reactivation as well.
> 
> It seems to be good idea. but I have a concern about embedded.
> AFAIK, some CPUs don't have accessed bit by hardware.
> maybe ARM series.
> (Nowadays, Some kinds of CPU series just supports access bit.
> but there are still CPUs that doesn't support it)
> 
> I am not sure there are others architecture.
> Your idea makes mapped page reclaim depend on access bit more tightly.
>  :(

ARM seems to emulate the accessed bit by ensuring a subsequent access
will fault when the young bit is cleared, so we should get one extra
minor fault per finally activated mapped file page as a trade-off.

I am not too concerned about that because it should be a rather rare
event.  Only fresh pages go through that.  PG_referenced is remembered
over activation/deactivation and once it's set, a page is treated just
like it is now: activated if referenced, reclaimed if not.

So yeah, there is a bit more overhead for ARM to approximate the
working set initially.  But the results are more trustworthy and we
get rid of a badly performing corner case in the VM.

> > diff --git a/mm/rmap.c b/mm/rmap.c
> > index 28aafe2..0c88813 100644
> > --- a/mm/rmap.c
> > +++ b/mm/rmap.c
> > @@ -508,9 +508,6 @@ int page_referenced(struct page *page,
> > A {
> > A  A  A  A int referenced = 0;
> >
> > - A  A  A  if (TestClearPageReferenced(page))
> > - A  A  A  A  A  A  A  referenced++;
> > -

This hunk should also get removed from the !CONFIG_MMU dummy function.
I'll wait a bit for more feedback and send a fixed revision.

Thanks,
	Hannes

--
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:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2009-09-16 19:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-14 23:46 [patch] mm: use-once mapped file pages Johannes Weiner
2009-09-14 23:46 ` Johannes Weiner
2009-09-15 15:26 ` Minchan Kim
2009-09-15 15:26   ` Minchan Kim
2009-09-15 16:01   ` Rik van Riel
2009-09-15 16:01     ` Rik van Riel
2009-09-16 19:04   ` Johannes Weiner [this message]
2009-09-16 19:04     ` Johannes Weiner

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=20090916190431.GA20897@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan.kim@gmail.com \
    --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 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.