[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51F0E52C.1080101@parallels.com>
Date: Thu, 25 Jul 2013 12:43:24 +0400
From: Pavel Emelyanov <xemul@...allels.com>
To: Hush Bensen <hush.bensen@...il.com>
CC: Andy Lutomirski <luto@...capital.net>,
Cyrill Gorcunov <gorcunov@...il.com>,
James Bottomley <James.Bottomley@...senpartnership.com>,
Linux MM <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Matt Mackall <mpm@...enic.com>,
Xiao Guangrong <xiaoguangrong@...ux.vnet.ibm.com>,
Marcelo Tosatti <mtosatti@...hat.com>,
KOSAKI Motohiro <kosaki.motohiro@...il.com>,
Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [PATCH] mm: Save soft-dirty bits on swapped pages
On 07/25/2013 12:26 PM, Hush Bensen wrote:
> On 07/25/2013 03:29 PM, Pavel Emelyanov wrote:
>> On 07/24/2013 11:40 PM, Andy Lutomirski wrote:
>>> On Wed, Jul 24, 2013 at 12:04 PM, Cyrill Gorcunov <gorcunov@...il.com> wrote:
>>>> On Wed, Jul 24, 2013 at 10:55:41PM +0400, Pavel Emelyanov wrote:
>>>>>> Well, some part of information already lays in pte (such as 'file' bit,
>>>>>> swap entries) so it looks natural i think to work on this level. but
>>>>>> letme think if use page struct for that be more convenient...
>>>>> It hardly will be. Consider we have a page shared between two tasks,
>>>>> then first one "touches" it and soft-dirty is put onto his PTE and,
>>>>> subsequently, the page itself. The we go and clear sofr-dirty for the
>>>>> 2nd task. What should we do with the soft-dirty bit on the page?
>>>> Indeed, this won't help. Well then, bippidy-boppidy-boo, our
>>>> pants are metaphorically on fire (c)
>>> Hmm. So there are at least three kinds of memory:
>>>
>>> Anonymous pages: soft-dirty works
>>> Shared file-backed pages: soft-dirty does not work
>>> Private file-backed pages: soft-dirty works (but see below)
>> The shared file-backed pages case works, but unmap-map case doesn't
>
> What's the meaning of unmap-map case?
Unmap is what happens when Linux runs out of memory, starts memory
reclaim procedure and removes a page from task's address space, replacing
the respective pte with an information where (in swap or in file) the
page can be found.
Map is what occurs when the task touches the unmapped page again, the
respective page is read back from file/swap and the respective pte if
filled with its pfn.
This patch fixes the soft-dirty bit preservation during the unmap-map cycle
for pages, that go to swap.
Sorry for confusion.
>> preserve the soft-dirty bit. Just like the private file did. We'll
>> fix this case next.
Thanks,
Pavel
--
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