From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Hubertus Franke <frankeh@watson.ibm.com>
Cc: akpm@osdl.org, virtualization@lists.osdl.org, rhim@cc.gateh.edu,
nickpiggin@yahoo.com.au, linux-kernel@vger.kernel.org
Subject: Re: [patch 1/9] Guest page hinting: unused / free pages.
Date: Wed, 13 Sep 2006 14:45:35 +0200 [thread overview]
Message-ID: <1158151535.2560.20.camel@localhost> (raw)
In-Reply-To: <4507F453.1040809@watson.ibm.com>
On Wed, 2006-09-13 at 08:06 -0400, Hubertus Franke wrote:
> Martin Schwidefsky wrote:
> > On Tue, 2006-09-12 at 21:29 -0400, Rik van Riel wrote:
> >
> >>Note that the transition _to_ volatile can also be batched
> >>and done somewhat lazily. For frequently mmaped pages that
> >>could end up saving us the transition the other way, too...
> >
> >
> > That would be helpful, only how to do it? We need some sort of list or
> > array where to store the pages that should be made volatile. The main
> > problem that I see is that you have to remove a page that is freed from
> > the list/array again, otherwise you would end up with a non page-cache
> > page being made volatile. That makes using per-cpu arrays hard since a
> > page can be freed on another cpu.
> >
>
>
> Martin. the point was that pages
> which are in the hold/cold lists are technically free.
> However we keep them stable.
> When the hot/cold list is spilled back to the buddy allocator
> we make them volatile in buld (i.e. through the array).
You mean unused.
> So we only build the array for the duration of the bulk-release
> to the buddy allocator (and potentially the other way as well).
> Hence there is no "state" to maintain or track for the array.
> Pages in the hot/cold lists remain stable.
> This would not any of the problems you described as long as we hold
> the lock for the hot/cold list during buld-volatile.
I was not talking about free pages, and I don't think Rik was either.
The idea is to be lazy about the make-volatile calls. Put the pages for
which a make-volatile call should be done to some array/list and do a
bulk make-volatile. These pages are still in the page/swap cache. The
trouble is we have to be sure these pages have not been freed in the
meantime.
The bulk set-unused/set-stable to the buddy allocator should not be to
problematic. We just have to find new places where to do the calls.
--
blue skies,
Martin.
Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH
"Reality continues to ruin my life." - Calvin.
WARNING: multiple messages have this Message-ID (diff)
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Hubertus Franke <frankeh@watson.ibm.com>
Cc: Rik van Riel <riel@redhat.com>,
linux-kernel@vger.kernel.org, virtualization@lists.osdl.org,
akpm@osdl.org, nickpiggin@yahoo.com.au, rhim@cc.gateh.edu
Subject: Re: [patch 1/9] Guest page hinting: unused / free pages.
Date: Wed, 13 Sep 2006 14:45:35 +0200 [thread overview]
Message-ID: <1158151535.2560.20.camel@localhost> (raw)
In-Reply-To: <4507F453.1040809@watson.ibm.com>
On Wed, 2006-09-13 at 08:06 -0400, Hubertus Franke wrote:
> Martin Schwidefsky wrote:
> > On Tue, 2006-09-12 at 21:29 -0400, Rik van Riel wrote:
> >
> >>Note that the transition _to_ volatile can also be batched
> >>and done somewhat lazily. For frequently mmaped pages that
> >>could end up saving us the transition the other way, too...
> >
> >
> > That would be helpful, only how to do it? We need some sort of list or
> > array where to store the pages that should be made volatile. The main
> > problem that I see is that you have to remove a page that is freed from
> > the list/array again, otherwise you would end up with a non page-cache
> > page being made volatile. That makes using per-cpu arrays hard since a
> > page can be freed on another cpu.
> >
>
>
> Martin. the point was that pages
> which are in the hold/cold lists are technically free.
> However we keep them stable.
> When the hot/cold list is spilled back to the buddy allocator
> we make them volatile in buld (i.e. through the array).
You mean unused.
> So we only build the array for the duration of the bulk-release
> to the buddy allocator (and potentially the other way as well).
> Hence there is no "state" to maintain or track for the array.
> Pages in the hot/cold lists remain stable.
> This would not any of the problems you described as long as we hold
> the lock for the hot/cold list during buld-volatile.
I was not talking about free pages, and I don't think Rik was either.
The idea is to be lazy about the make-volatile calls. Put the pages for
which a make-volatile call should be done to some array/list and do a
bulk make-volatile. These pages are still in the page/swap cache. The
trouble is we have to be sure these pages have not been freed in the
meantime.
The bulk set-unused/set-stable to the buddy allocator should not be to
problematic. We just have to find new places where to do the calls.
--
blue skies,
Martin.
Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH
"Reality continues to ruin my life." - Calvin.
next prev parent reply other threads:[~2006-09-13 12:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-01 11:09 [patch 1/9] Guest page hinting: unused / free pages Martin Schwidefsky
2006-09-01 15:33 ` Dave Hansen
2006-09-01 15:33 ` Dave Hansen
2006-09-01 15:43 ` Martin Schwidefsky
2006-09-01 15:56 ` Dave Hansen
2006-09-01 15:56 ` Dave Hansen
2006-09-01 16:05 ` Martin Schwidefsky
2006-09-01 16:10 ` Dave Hansen
2006-09-01 16:10 ` Dave Hansen
2006-09-12 22:47 ` Rik van Riel
2006-09-13 0:07 ` Hubertus Franke
2006-09-13 0:07 ` Hubertus Franke
2006-09-13 1:29 ` Rik van Riel
2006-09-13 8:56 ` Martin Schwidefsky
2006-09-13 8:56 ` Martin Schwidefsky
2006-09-13 12:06 ` Hubertus Franke
2006-09-13 12:45 ` Martin Schwidefsky [this message]
2006-09-13 12:45 ` Martin Schwidefsky
2006-09-13 13:06 ` Hubertus Franke
2006-09-13 14:45 ` Rik van Riel
2006-09-13 14:59 ` Martin Schwidefsky
2006-09-13 14:59 ` Martin Schwidefsky
2006-09-13 17:05 ` Hubertus Franke
-- strict thread matches above, loose matches on Subject: below --
2006-08-24 14:29 Martin Schwidefsky, Martin Schwidefsky, Hubertus Franke, Himanshu Raj
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=1158151535.2560.20.camel@localhost \
--to=schwidefsky@de.ibm.com \
--cc=akpm@osdl.org \
--cc=frankeh@watson.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=rhim@cc.gateh.edu \
--cc=virtualization@lists.osdl.org \
/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.