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 S1753114AbbJ1WYd (ORCPT <rfc822;w@1wt.eu>);
	Wed, 28 Oct 2015 18:24:33 -0400
Received: from mx1.redhat.com ([209.132.183.28]:35850 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751234AbbJ1WYc (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 28 Oct 2015 18:24:32 -0400
From: Jeff Moyer <jmoyer@redhat.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, linux-nvdimm@ml01.01.org,
        Dave Chinner <david@fromorbit.com>, x86@kernel.org,
        Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
        Thomas Gleixner <tglx@linutronix.de>, Jan Kara <jack@suse.com>
Subject: Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness
References: <1446070176-14568-1-git-send-email-ross.zwisler@linux.intel.com>
X-PGP-KeyID: 1F78E1B4
X-PGP-CertKey: F6FE 280D 8293 F72C 65FD  5A58 1FF8 A7CA 1F78 E1B4
X-PCLoadLetter: What the f**k does that mean?
Date: Wed, 28 Oct 2015 18:24:29 -0400
In-Reply-To: <1446070176-14568-1-git-send-email-ross.zwisler@linux.intel.com>
	(Ross Zwisler's message of "Wed, 28 Oct 2015 16:09:34 -0600")
Message-ID: <x49lhamljhe.fsf@segfault.boston.devel.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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?

> I do worry that the cost of blindly flushing the entire PMEM namespace on each
> fsync or msync will be prohibitively expensive, and that we'll by very
> incentivized to move to the radix tree based dirty page tracking as soon as
> possible. :)

Sure, but wbinvd would be quite costly as well.  Either way I think a
better solution will be required in the near term.

Cheers,
Jeff