Linux-NVDIMM Archive on
 help / color / Atom feed
From: "Aneesh Kumar K.V" <>
To: Jeff Moyer <>, Dan Williams <>
Cc: linuxppc-dev <>,
	Michael Ellerman <>,
	linux-nvdimm <>,,,
	Jan Kara <>
Subject: Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier
Date: Thu, 21 May 2020 22:32:51 +0530
Message-ID: <> (raw)
In-Reply-To: <>

On 5/21/20 8:08 PM, Jeff Moyer wrote:
> Dan Williams <> writes:
>>> But I agree with your concern that if we have older kernel/applications
>>> that continue to use `dcbf` on future hardware we will end up
>>> having issues w.r.t powerfail consistency. The plan is what you outlined
>>> above as tighter ecosystem control. Considering we don't have a pmem
>>> device generally available, we get both kernel and userspace upgraded
>>> to use these new instructions before such a device is made available.
> I thought power already supported NVDIMM-N, no?  So are you saying that
> those devices will continue to work with the existing flushing and
> fencing mechanisms?

yes. these devices can continue to use 'dcbf + hwsync' as long as we are 
running them on P9.

>> Ok, I think a compile time kernel option with a runtime override
>> satisfies my concern. Does that work for you?
> The compile time option only helps when running newer kernels.  I'm not
> sure how you would even begin to audit userspace applications (keep in
> mind, not every application is open source, and not every application
> uses pmdk).  I also question the merits of forcing the administrator to
> make the determination of whether all applications on the system will
> work properly.  Really, you have to rely on the vendor to tell you the
> platform is supported, and at that point, why put further hurdles in the
> way?
> The decision to require different instructions on ppc is unfortunate,
> but one I'm sure we have no control over.  I don't see any merit in the
> kernel disallowing MAP_SYNC access on these platforms.  Ideally, we'd
> have some way of ensuring older kernels don't work with these new
> platforms, but I don't think that's possible.

I am currently looking at the possibility of firmware present these 
devices with different device-tree compat values. So that older 
/existing kernel won't initialize the device on newer systems. Is that a 
good compromise? We still can end up with older userspace and newer 
kernel. One of the option suggested by Jan Kara is to use a prctl flag 
to control that? (intead of kernel parameter option I posted before)

> Moving on to the patch itself--Aneesh, have you audited other persistent
> memory users in the kernel?  For example, drivers/md/dm-writecache.c does
> this:
> static void writecache_commit_flushed(struct dm_writecache *wc, bool wait_for_ios)
> {
>   	if (WC_MODE_PMEM(wc))
> 	        wmb(); <==========
>          else
>                  ssd_commit_flushed(wc, wait_for_ios);
> }
> I believe you'll need to make modifications there.

Correct. Thanks for catching that.

I don't understand dm much, wondering how this will work with 
non-synchronous DAX device?

Linux-nvdimm mailing list --
To unsubscribe send an email to

  reply index

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-13  3:47 [PATCH v2 1/5] powerpc/pmem: Add new instructions for persistent storage and sync Aneesh Kumar K.V
2020-05-13  3:47 ` [PATCH v2 2/5] powerpc/pmem: Add flush routines using new pmem store and sync instruction Aneesh Kumar K.V
2020-05-13  3:47 ` [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier Aneesh Kumar K.V
2020-05-13 16:14   ` Dan Williams
2020-05-19  5:30     ` Aneesh Kumar K.V
2020-05-19  7:09       ` Dan Williams
2020-05-19 13:52         ` Aneesh Kumar K.V
2020-05-19 18:59           ` Dan Williams
2020-05-20 18:43             ` Aneesh Kumar K.V
2020-05-21 14:38             ` Jeff Moyer
2020-05-21 17:02               ` Aneesh Kumar K.V [this message]
2020-05-21 18:25                 ` Dan Williams
2020-05-21 18:52                   ` Mikulas Patocka
2020-05-22  9:31                     ` Michal Suchánek
2020-05-22 10:08                       ` Aneesh Kumar K.V
2020-05-22 13:01                         ` Mikulas Patocka
2020-05-21 18:34               ` Dan Williams
2020-05-13  3:47 ` [PATCH v2 4/5] powerpc/pmem/of_pmem: Update of_pmem to use the new barrier instruction Aneesh Kumar K.V
2020-05-13  6:44   ` kbuild test robot
2020-05-13  3:47 ` [PATCH v2 5/5] powerpc/pmem: Avoid the barrier in flush routines Aneesh Kumar K.V

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-NVDIMM Archive on

Archives are clonable:
	git clone --mirror linux-nvdimm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-nvdimm linux-nvdimm/ \
	public-inbox-index linux-nvdimm

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone