linux-kernel - Re: fadvise DONTNEED implementation (or lack thereof)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/