[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CE49C8B.2050005@redhat.com>
Date: Wed, 17 Nov 2010 22:24:59 -0500
From: Rik van Riel <riel@...hat.com>
To: Minchan Kim <minchan.kim@...il.com>
CC: Peter Zijlstra <peterz@...radead.org>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Ben Gamari <bgamari.foss@...il.com>,
linux-kernel@...r.kernel.org, rsync@...ts.samba.org,
linux-mm@...ck.org, Wu Fengguang <fengguang.wu@...el.com>
Subject: Re: fadvise DONTNEED implementation (or lack thereof)
On 11/17/2010 09:47 PM, Minchan Kim wrote:
> On Thu, Nov 18, 2010 at 1:22 AM, Rik van Riel<riel@...hat.com> wrote:
>> On 11/17/2010 05:16 AM, Minchan Kim wrote:
>>
>>> Absolutely. But how about rsync's two touch?
>>> It can evict working set.
>>>
>>> I need the time for investigation.
>>> Thanks for the comment.
>>
>> Maybe we could exempt MADV_SEQUENTIAL and FADV_SEQUENTIAL
>> touches from promoting the page to the active list?
>>
>
> The problem is non-mapped file page.
> non-mapped file page promotion happens by only mark_page_accessed.
> But it doesn't enough information to prevent promotion(ex, vma or file)
I believe we have enough information in filemap.c and can just
pass that as a parameter to mark_page_accessed.
> Here is another idea.
> Current problem is following as.
> User can use fadivse with FADV_DONTNEED.
> But problem is that it can't affect when it meet dirty pages.
> So user have to sync dirty page before calling fadvise with FADV_DONTNEED.
> It would lose performance.
>
> Let's add some semantic of FADV_DONTNEED.
> It invalidates only pages which are not dirty.
> If it meets dirty page, let's move the page into inactive's tail or head.
> If we move the page into tail, shrinker can move it into head again
> for deferred write if it isn't written the backed device.
That sounds like a good idea.
--
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