[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALvZod73huYukNBUvn3XS40V4SQYk4H5_Jhv4Qp0446-d4P0rg@mail.gmail.com>
Date: Tue, 22 Aug 2017 17:25:00 -0700
From: Shakeel Butt <shakeelb@...gle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Mel Gorman <mgorman@...e.de>, Johannes Weiner <hannes@...xchg.org>,
Hillf Danton <hillf.zj@...baba-inc.com>,
Vlastimil Babka <vbabka@...e.cz>,
Hugh Dickins <hughd@...gle.com>,
Greg Thelen <gthelen@...gle.com>,
Linux MM <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] mm: fadvise: avoid fadvise for fs without backing device
>> It doesn't sound like a risky change to me, although perhaps someone is
>> depending on the current behaviour for obscure reasons, who knows.
>>
>> What are the reasons for this change? Is the current behaviour causing
>> some sort of problem for someone?
>
> Yes, one of our generic library does fadvise(FADV_DONTNEED). Recently
> we observed high latency in fadvise() and notice that the users have
> started using tmpfs files and the latency was due to expensive remote
> LRU cache draining. For normal tmpfs files (have data written on
> them), fadvise(FADV_DONTNEED) will always trigger the un-needed remote
> cache draining.
>
Hi Andrew, do you have more comments or concerns?
>>
>>
Powered by blists - more mailing lists