From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1164149AbdD0SlS (ORCPT ); Thu, 27 Apr 2017 14:41:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52778 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031925AbdD0SlL (ORCPT ); Thu, 27 Apr 2017 14:41:11 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A33F480066 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jmoyer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A33F480066 From: Jeff Moyer To: Dan Williams Cc: "linux-nvdimm\@lists.01.org" , Masayoshi Mizuma , Linux ACPI , "linux-kernel\@vger.kernel.org" Subject: Re: [PATCH v3] libnvdimm, region: sysfs trigger for nvdimm_flush() References: <149307780135.7155.11108531648914675756.stgit@dwillia2-desk3.amr.corp.intel.com> <149315140303.23340.14688142799059150805.stgit@dwillia2-desk3.amr.corp.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: Thu, 27 Apr 2017 14:41:08 -0400 In-Reply-To: (Dan Williams's message of "Thu, 27 Apr 2017 09:56:44 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 27 Apr 2017 18:41:10 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dan Williams writes: >> The sentiment is that programs shouldn't have to grovel around in sysfs >> to do stuff related to an open file descriptor or mapping. I don't take >> issue with the name. I do worry that something like 'wpq_drain' may be >> too platform specific, though. The NVM Programming Model specification >> is going to call this "deep flush", so maybe that will give you >> some inspiration if you do want to change the name. > > I'll change to "deep_flush", and I quibble that this is related to a > single open file descriptor or mapping. It really is a "region flush" > for giving extra protection for global metadata, but the persistence > of individual fds or mappings is handled by ADR. I think an ioctl > might give the false impression that every time you flush a cacheline > to persistence you need to call the ioctl. fsync, for example, may affect more than one fd--all data in the drive write cache will be flushed. I don't see how this is so different. I think a sysfs file is awkward because it requires an application to chase down the correct file in the sysfs hierarchy. If the application already has an open fd or a mapping, it should be able to operate on that. As for confusion on when to use the interface, I think that's inevitable no matter how it's implemented. We're introducing a flush type that has never been exposed before, and we're not giving any information on how likely an ADR failure is, or how expensive this flush will be. Cheers, Jeff