[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Nov 2008 00:36:00 +0200
From: Avi Kivity <avi@...hat.com>
To: Christoph Lameter <cl@...ux-foundation.org>
CC: Andrea Arcangeli <aarcange@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Izik Eidus <ieidus@...hat.com>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, kvm@...r.kernel.org, chrisw@...hat.com,
izike@...ranet.com
Subject: Re: [PATCH 2/4] Add replace_page(), change the mapping of pte from
one page into another
Christoph Lameter wrote:
> On Tue, 11 Nov 2008, Avi Kivity wrote:
>
>
>> Christoph Lameter wrote:
>>
>>> page migration requires the page to be on the LRU. That could be changed
>>> if you have a different means of isolating a page from its page tables.
>>>
>>>
>> Isn't rmap the means of isolating a page from its page tables? I guess I'm
>> misunderstanding something.
>>
>
> In order to migrate a page one first has to make sure that userspace and
> the kernel cannot access the page in any way. User space must be made to
> generate page faults and all kernel references must be accounted for and
> not be in use.
>
> The user space portion involves changing the page tables so that faults
> are generated.
>
> The kernel portion isolates the page from the LRU (to exempt it from
> kernel reclaim handling etc).
>
>
Thanks.
> Only then can the page and its metadata be copied to a new location.
>
> Guess you already have the LRU portion done. So you just need the user
> space isolation portion?
>
We don't want to limit all faults, just writes. So we write protect the
page before merging.
What do you mean by page metadata? obviously the dirty bit (Izik?),
accessed bit and position in the LRU are desirable (the last is quite
difficult for ksm -- the page occupied *two* positions in the LRU).
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
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