[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A7993F4.9020008@redhat.com>
Date: Wed, 05 Aug 2009 10:15:16 -0400
From: Rik van Riel <riel@...hat.com>
To: Avi Kivity <avi@...hat.com>
CC: Wu Fengguang <fengguang.wu@...el.com>,
"Dike, Jeffrey G" <jeffrey.g.dike@...el.com>,
"Yu, Wilfred" <wilfred.yu@...el.com>,
"Kleen, Andi" <andi.kleen@...el.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Hugh Dickins <hugh.dickins@...cali.co.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Christoph Lameter <cl@...ux-foundation.org>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Mel Gorman <mel@....ul.ie>,
LKML <linux-kernel@...r.kernel.org>,
linux-mm <linux-mm@...ck.org>
Subject: Re: [RFC] respect the referenced bit of KVM guest pages?
Avi Kivity wrote:
>> However it risks reintroducing the problem addressed by commit 7e9cd4842
>> (fix reclaim scalability problem by ignoring the referenced bit,
>> mainly the pte young bit). I wonder if there are better solutions?
Agreed, we need to figure out what the real problem is,
and how to solve it better.
> Jeff, do you see the refaults on Nehalem systems? If so, that's likely
> due to the lack of an accessed bit on EPT pagetables. It would be
> interesting to compare with Barcelona (which does).
Not having a hardware accessed bit would explain why
the VM is not reactivating the pages that were accessed
while on the inactive list.
> If that's indeed the case, we can have the EPT ageing mechanism give
> pages a bit more time around by using an available bit in the EPT PTEs
> to return accessed on the first pass and not-accessed on the second.
Can we find out which pages are EPT pages?
If so, we could unmap them when they get moved from the
active to the inactive list, and soft fault them back in
on access, emulating the referenced bit for EPT pages and
making page replacement on them work like it should.
Your approximation of pretending the page is accessed the
first time and pretending it's not the second time sounds
like it will just lead to less efficient FIFO replacement,
not to anything even vaguely approximating LRU.
--
All rights reversed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists