From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: Jeff Moyer <jmoyer@redhat.com>, Dan Williams <dan.j.williams@intel.com>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Michael Ellerman <mpe@ellerman.id.au>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
alistair@popple.id.au, mpatocka@redhat.com,
Jan Kara <jack@suse.cz>
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 [thread overview]
Message-ID: <ba91c061-41ef-5c54-8e9b-7b22e44577cd@linux.ibm.com> (raw)
In-Reply-To: <x49o8qh9wu5.fsf@segfault.boston.devel.redhat.com>
On 5/21/20 8:08 PM, Jeff Moyer wrote:
> Dan Williams <dan.j.williams@intel.com> 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?
-aneesh
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
next prev parent reply other threads:[~2020-05-21 17:03 UTC|newest]
Thread overview: 21+ 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-06-26 10:20 ` Michal Suchánek
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ba91c061-41ef-5c54-8e9b-7b22e44577cd@linux.ibm.com \
--to=aneesh.kumar@linux.ibm.com \
--cc=alistair@popple.id.au \
--cc=dan.j.williams@intel.com \
--cc=jack@suse.cz \
--cc=jmoyer@redhat.com \
--cc=linux-nvdimm@lists.01.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpatocka@redhat.com \
--cc=mpe@ellerman.id.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).