[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090805163143.GF23385@random.random>
Date: Wed, 5 Aug 2009 18:31:43 +0200
From: Andrea Arcangeli <aarcange@...hat.com>
To: Rik van Riel <riel@...hat.com>
Cc: Avi Kivity <avi@...hat.com>, 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>,
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?
On Wed, Aug 05, 2009 at 10:15:16AM -0400, Rik van Riel wrote:
> Not having a hardware accessed bit would explain why
> the VM is not reactivating the pages that were accessed
> while on the inactive list.
Problem is, even with young bit functional the VM isn't reactivating
those pages anyway because of that broken check... That check should
be nuked entirely in my view as it fundamentally thinks it can
outsmart the VM intelligence by checking a bit in the vma... quite
absurd in my view.
> 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.
I think it'll still better than current situation, as young bit is
always set for ptes. Otherwise EPT pages are too penalized, we need
them to stay one round more in active list like everything else. They
are too penalizied anyways because at second pass they'll be forced
out of active list and unmapped.
This is what alpha and all other archs without young bit set in
hardware have to do. They set young bit in software and clear it in
software and then set it again in software if there's a page fault
(hopefully a minor fault). Returning "not young" first time sounds
worse to me.
--
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