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 S1162868AbbKFUZq (ORCPT <rfc822;w@1wt.eu>);
	Fri, 6 Nov 2015 15:25:46 -0500
Received: from terminus.zytor.com ([198.137.202.10]:55103 "EHLO mail.zytor.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1162794AbbKFUZn (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 6 Nov 2015 15:25:43 -0500
User-Agent: K-9 Mail for Android
In-Reply-To: <CAPcyv4jYc_Ai+9st_QgzuWNMMHCQ-j6pe4R0XEWy5-mEb1_X5Q@mail.gmail.com>
References: <1446070176-14568-1-git-send-email-ross.zwisler@linux.intel.com> <x49lhamljhe.fsf@segfault.boston.devel.redhat.com> <20151028225112.GA30284@linux.intel.com> <CAPcyv4jYc_Ai+9st_QgzuWNMMHCQ-j6pe4R0XEWy5-mEb1_X5Q@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Subject: Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Fri, 06 Nov 2015 12:25:15 -0800
To: Dan Williams <dan.j.williams@intel.com>,
        Ross Zwisler <ross.zwisler@linux.intel.com>
CC: Jeff Moyer <jmoyer@redhat.com>, linux-nvdimm <linux-nvdimm@ml01.01.org>,
        X86 ML <x86@kernel.org>, Dave Chinner <david@fromorbit.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Ingo Molnar <mingo@redhat.com>, Thomas Gleixner <tglx@linutronix.de>,
        Jan Kara <jack@suse.com>
Message-ID: <6BAC06FA-C855-4897-95C2-02BCA01C28A6@zytor.com>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On November 5, 2015 3:59:46 PM PST, Dan Williams <dan.j.williams@intel.com> wrote:
>On Wed, Oct 28, 2015 at 3:51 PM, Ross Zwisler
><ross.zwisler@linux.intel.com> wrote:
>> On Wed, Oct 28, 2015 at 06:24:29PM -0400, Jeff Moyer wrote:
>>> Ross Zwisler <ross.zwisler@linux.intel.com> writes:
>>>
>>> > This series implements the very slow but correct handling for
>>> > blkdev_issue_flush() with DAX mappings, as discussed here:
>>> >
>>> > https://lkml.org/lkml/2015/10/26/116
>>> >
>>> > I don't think that we can actually do the
>>> >
>>> >     on_each_cpu(sync_cache, ...);
>>> >
>>> > ...where sync_cache is something like:
>>> >
>>> >     cache_disable();
>>> >     wbinvd();
>>> >     pcommit();
>>> >     cache_enable();
>>> >
>>> > solution as proposed by Dan because WBINVD + PCOMMIT doesn't
>guarantee that
>>> > your writes actually make it durably onto the DIMMs.  I believe
>you really do
>>> > need to loop through the cache lines, flush them with CLWB, then
>fence and
>>> > PCOMMIT.
>>>
>>> *blink*
>>> *blink*
>>>
>>> So much for not violating the principal of least surprise.  I
>suppose
>>> you've asked the hardware folks, and they've sent you down this
>path?
>>
>> Sadly, yes, this was the guidance from the hardware folks.
>
>So it turns out we weren't asking the right question.  wbinvd may
>indeed be viable... we're still working through the caveats.

Do not disable the caches here.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.