xfs
[Top] [All Lists]

Re: [PATCH v2 2/3] mm, dax: add VM_DAX flag for DAX VMAs

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH v2 2/3] mm, dax: add VM_DAX flag for DAX VMAs
From: Dan Williams <dan.j.williams@xxxxxxxxx>
Date: Thu, 15 Sep 2016 17:16:42 -0700
Cc: Christoph Hellwig <hch@xxxxxx>, Linux MM <linux-mm@xxxxxxxxx>, "linux-nvdimm@xxxxxxxxxxxx" <linux-nvdimm@xxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Nicholas Piggin <npiggin@xxxxxxxxx>, XFS Developers <xfs@xxxxxxxxxxx>, linux-fsdevel <linux-fsdevel@xxxxxxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tWSCbOgGvtJd31V7QZghTpYHAWP9wr6N8A2zK4XIguM=; b=0VLPfryJH7FeaFIHNtVvE/jF688SGKbwdTNu20d+FlKuQvVpmefHqU5SOqRPuX5BaN TTHtPbO6QUd7xmPUcLu3viHi3aYBoHzUK3Ti9QFAixF0Q1WWOi18XhsEkhFv+arpolhP xrJTTlsO/TyPjVM3e4KesSruKnyNGGrAkYzY9sgitKu1JXlmxYYP55Rj4yu35KWfQsrH J5W3NUwahe5eD32UsX3e2vDHctaay5KMkPj1+rG2TXHp1OSUZzelj9BruVtzFimTfqbh /qJ+1VQcnOnhkC8Qe2WRkoQr4lAqgx5Xg5NLHn85mnCBBtu5X2lkeS+ua58MjZFoqvqs kEAw==
In-reply-to: <20160915230748.GS30497@dastard>
References: <147392246509.9873.17750323049785100997.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <147392247875.9873.4205533916442000884.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20160915082615.GA9772@xxxxxx> <CAPcyv4jTw3cXpmmJRh7t16Xy2uYofDe+fJ+X_jnz+Q=o0uGneg@xxxxxxxxxxxxxx> <20160915230748.GS30497@dastard>
On Thu, Sep 15, 2016 at 4:07 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> On Thu, Sep 15, 2016 at 10:01:03AM -0700, Dan Williams wrote:
>> On Thu, Sep 15, 2016 at 1:26 AM, Christoph Hellwig <hch@xxxxxx> wrote:
>> > On Wed, Sep 14, 2016 at 11:54:38PM -0700, Dan Williams wrote:
>> >> The DAX property, page cache bypass, of a VMA is only detectable via the
>> >> vma_is_dax() helper to check the S_DAX inode flag.  However, this is
>> >> only available internal to the kernel and is a property that userspace
>> >> applications would like to interrogate.
>> >
>> > They have absolutely no business knowing such an implementation detail.
>>
>> Hasn't that train already left the station with FS_XFLAG_DAX?
>
> No, that's an admin flag, not a runtime hint for applications. Just
> because that flag is set on an inode, it does not mean that DAX is
> actually in use - it will be ignored if the backing dev is not dax
> capable.
>

What's the point of an admin flag if an admin can't do cat /proc/<pid
of interest>/smaps, or some other mechanism, to validate that the
setting the admin cares about is in effect?

<Prev in Thread] Current Thread [Next in Thread>