xfs
[Top] [All Lists]

Re: [PATCH v2 03/11] pmem: enable REQ_FUA/REQ_FLUSH handling

To: Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx>, Dan Williams <dan.j.williams@xxxxxxxxx>, Jan Kara <jack@xxxxxxx>, Andreas Dilger <adilger@xxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, "J. Bruce Fields" <bfields@xxxxxxxxxxxx>, "Theodore Ts'o" <tytso@xxxxxxx>, Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Jan Kara <jack@xxxxxxxx>, Jeff Layton <jlayton@xxxxxxxxxxxxxxx>, Matthew Wilcox <willy@xxxxxxxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, linux-ext4 <linux-ext4@xxxxxxxxxxxxxxx>, linux-fsdevel <linux-fsdevel@xxxxxxxxxxxxxxx>, Linux MM <linux-mm@xxxxxxxxx>, "linux-nvdimm@xxxxxxxxxxxx" <linux-nvdimm@xxxxxxxxxxxx>, X86 ML <x86@xxxxxxxxxx>, XFS Developers <xfs@xxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Matthew Wilcox <matthew.r.wilcox@xxxxxxxxx>, Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
Subject: Re: [PATCH v2 03/11] pmem: enable REQ_FUA/REQ_FLUSH handling
From: Dan Williams <dan.j.williams@xxxxxxxxx>
Date: Mon, 16 Nov 2015 12:34:55 -0800
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:date:message-id:subject:from:to :content-type; bh=oeTr6SZaYSbqNbHYUymYGCuZ3dhCmluCBCkD+SFiVKw=; b=PsrfrtZEXwiof3yAHI4f+nHUV7YVJm4Tkh2kogFs7YuKc9A2YcmK9uPSnwGfFNwUsC g4cSIycAulQGa6pEhi4CwMbSD7vBB8Fd91rGlutafVoTLe6MPiKC65mx9HnLY3Es978h FyhJm5ylin5bZwcaWB0RDVIfUCwQVnQ8ZsEki5LCetEPmjlY0R9kG1a31DdNNrTy44ES ee4cmoRzbEtQYo3e4v+E7FNtitCmgnhPw09MlsCb2G0gms8znwywQvAtcqEvQtyS0vOs ytv/VEekttOnxgqU0Jmrkjk4usPrYhDBZsyB6FrMxYT5Ecn54KiUnCUO/1EtrpaVBneH 44ew==
In-reply-to: <20151116194846.GB32203@xxxxxxxxxxxxxxx>
References: <1447459610-14259-1-git-send-email-ross.zwisler@xxxxxxxxxxxxxxx> <1447459610-14259-4-git-send-email-ross.zwisler@xxxxxxxxxxxxxxx> <CAPcyv4j4arHE+iAALn1WPDzSb_QSCDy8udtXU1FV=kYSZDfv8A@xxxxxxxxxxxxxx> <22E0F870-C1FB-431E-BF6C-B395A09A2B0D@xxxxxxxxx> <CAPcyv4jwx3VzyRugcpH7KCOKM64kJ4Bq4wgY=iNJMvLTHrBv-Q@xxxxxxxxxxxxxx> <20151116133714.GB3443@xxxxxxxxxxxxx> <20151116140526.GA6733@xxxxxxxxxxxxx> <CAPcyv4jZjnkz2YYtGWmkA23KAUMT092kjRtFkJ3QrzgPfTucfA@xxxxxxxxxxxxxx> <20151116194846.GB32203@xxxxxxxxxxxxxxx>
On Mon, Nov 16, 2015 at 11:48 AM, Ross Zwisler
<ross.zwisler@xxxxxxxxxxxxxxx> wrote:
> On Mon, Nov 16, 2015 at 09:28:59AM -0800, Dan Williams wrote:
>> On Mon, Nov 16, 2015 at 6:05 AM, Jan Kara <jack@xxxxxxx> wrote:
>> > On Mon 16-11-15 14:37:14, Jan Kara wrote:
[..]
> Is there any reason why this wouldn't work or wouldn't be a good idea?

We don't have numbers to support the claim that pcommit is so
expensive as to need be deferred, especially if the upper layers are
already taking the hit on doing the flushes.

REQ_FLUSH, means flush your volatile write cache.  Currently all I/O
through the driver never hits a volatile cache so there's no need to
tell the block layer that we have a volatile write cache, especially
when you have the core mm taking responsibility for doing cache
maintenance for dax-mmap ranges.

We also don't have numbers on if/when wbinvd is a more performant solution.

tl;dr Now that we have a baseline implementation can we please use
data to make future arch decisions?

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