Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754113Ab0KRDqr (ORCPT ); Wed, 17 Nov 2010 22:46:47 -0500 Received: from mail-iw0-f174.google.com ([209.85.214.174]:42129 "EHLO mail-iw0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751532Ab0KRDqq convert rfc822-to-8bit (ORCPT ); Wed, 17 Nov 2010 22:46:46 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=h25C4OsLhRmjnvR0GAiBvCz1kqM5xi77IKgW525LWHWXzrvLMWo1zDtw1TjscTVgFe +lpCtSGGpLjDkVTCUZLSQpIq+2jNOMEawmpGnzRmtvE72RQzFyOvmrtAhRnQGkkc2MLj JvI5xIwv+PiPF6Vj25rja+scpeucWo10Fnpjc= MIME-Version: 1.0 In-Reply-To: <4CE49C8B.2050005@redhat.com> References: <20101109162525.BC87.A69D9226@jp.fujitsu.com> <877hgmr72o.fsf@gmail.com> <20101114140920.E013.A69D9226@jp.fujitsu.com> <1289810825.2109.469.camel@laptop> <4CE14848.2060805@redhat.com> <4CE40129.9060103@redhat.com> <4CE49C8B.2050005@redhat.com> Date: Thu, 18 Nov 2010 12:46:44 +0900 Message-ID: Subject: Re: fadvise DONTNEED implementation (or lack thereof) From: Minchan Kim To: Rik van Riel Cc: Peter Zijlstra , KOSAKI Motohiro , Ben Gamari , linux-kernel@vger.kernel.org, rsync@lists.samba.org, linux-mm@kvack.org, Wu Fengguang Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2011 Lines: 62 On Thu, Nov 18, 2010 at 12:24 PM, Rik van Riel wrote: > On 11/17/2010 09:47 PM, Minchan Kim wrote: >> >> On Thu, Nov 18, 2010 at 1:22 AM, Rik van Riel ?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. FADV_SEQUENTIAL is per file/vma semantic and It is used by many place. I think changing all those places isn't simple and I don't want to add new structure to propagate the information 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. I will implement it. Thanks, Rik. > > -- > All rights reversed > -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/