From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1758788AbdHYVuA (ORCPT <rfc822;w@1wt.eu>);
        Fri, 25 Aug 2017 17:50:00 -0400
Received: from mail.linuxfoundation.org ([140.211.169.12]:50392 "EHLO
        mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1756673AbdHYVt7 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 25 Aug 2017 17:49:59 -0400
Date: Fri, 25 Aug 2017 14:49:57 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: Shakeel Butt <shakeelb@google.com>
Cc: Mel Gorman <mgorman@suse.de>, Johannes Weiner <hannes@cmpxchg.org>,
        Hillf Danton <hillf.zj@alibaba-inc.com>,
        Vlastimil Babka <vbabka@suse.cz>, Hugh Dickins <hughd@google.com>,
        Greg Thelen <gthelen@google.com>, Linux MM <linux-mm@kvack.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] mm: fadvise: avoid fadvise for fs without backing
 device
Message-Id: <20170825144957.5d99dad605fed1dc2550d25c@linux-foundation.org>
In-Reply-To: <CALvZod444NZaw9wcdSMs5Y60a0cV4j9SEt-TLBJT34OJ_yg3CQ@mail.gmail.com>
References: <20170818011023.181465-1-shakeelb@google.com>
        <CALvZod444NZaw9wcdSMs5Y60a0cV4j9SEt-TLBJT34OJ_yg3CQ@mail.gmail.com>
X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 17 Aug 2017 18:20:17 -0700 Shakeel Butt <shakeelb@google.com> wrote:

> +linux-mm, linux-kernel
> 
> On Thu, Aug 17, 2017 at 6:10 PM, Shakeel Butt <shakeelb@google.com> wrote:
> > The fadvise() manpage is silent on fadvise()'s effect on
> > memory-based filesystems (shmem, hugetlbfs & ramfs) and pseudo
> > file systems (procfs, sysfs, kernfs). The current implementaion
> > of fadvise is mostly a noop for such filesystems except for
> > FADV_DONTNEED which will trigger expensive remote LRU cache
> > draining. This patch makes the noop of fadvise() on such file
> > systems very explicit.
> >
> > However this change has two side effects for ramfs and one for
> > tmpfs. First fadvise(FADV_DONTNEED) can remove the unmapped clean
> > zero'ed pages of ramfs (allocated through read, readahead & read
> > fault) and tmpfs (allocated through read fault). Also
> > fadvise(FADV_WILLNEED) on create such clean zero'ed pages for
> > ramfs.

That sentence makes no sense.  I assume "fadvise(FADV_WILLNEED) will
create"?