From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 2B9C921A07A82 for ; Mon, 22 Apr 2019 12:44:32 -0700 (PDT) Received: by mail-oi1-x242.google.com with SMTP id w139so9355374oie.9 for ; Mon, 22 Apr 2019 12:44:32 -0700 (PDT) MIME-Version: 1.0 References: <20190410040826.24371-1-pagupta@redhat.com> <20190410040826.24371-2-pagupta@redhat.com> <20190412083230.GA29850@quack2.suse.cz> <20190418161833.GA22970@infradead.org> In-Reply-To: From: Dan Williams Date: Mon, 22 Apr 2019 12:44:21 -0700 Message-ID: Subject: Re: [PATCH v5 1/6] libnvdimm: nd_region flush callback support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Jeff Moyer Cc: cohuck@redhat.com, Jan Kara , KVM list , "Michael S. Tsirkin" , Jason Wang , david , Qemu Developers , virtualization@lists.linux-foundation.org, Andreas Dilger , Ross Zwisler , Andrea Arcangeli , linux-nvdimm , David Hildenbrand , Matthew Wilcox , Christoph Hellwig , Linux ACPI , linux-ext4 , Len Brown , kilobyte@angband.pl, Rik van Riel , yuval shaia , Stefan Hajnoczi , Paolo Bonzini , lcapitulino@redhat.com, Kevin Wolf , Nitesh Narayan Lal , Theodore Ts'o , Xiao Guangrong , "Darrick J. Wong" , "Rafael J. Wysocki" , Linux Kernel Mailing List , linux-xfs , linux-fsdevel , Igor Mammedov List-ID: On Mon, Apr 22, 2019 at 8:59 AM Jeff Moyer wrote: > > Dan Williams writes: > > > On Thu, Apr 18, 2019 at 9:18 AM Christoph Hellwig wrote: > >> > >> On Thu, Apr 18, 2019 at 09:05:05AM -0700, Dan Williams wrote: > >> > > > I'd either add a comment about avoiding retpoline overhead here or just > >> > > > make ->flush == NULL mean generic_nvdimm_flush(). Just so that people don't > >> > > > get confused by the code. > >> > > > >> > > Isn't this premature optimization? I really don't like adding things > >> > > like this without some numbers to show it's worth it. > >> > > >> > I don't think it's premature given this optimization technique is > >> > already being deployed elsewhere, see: > >> > > >> > https://lwn.net/Articles/774347/ > >> > >> For one this one was backed by numbers, and second after feedback > >> from Linux we switched to the NULL pointer check instead. > > > > Ok I should have noticed the switch to NULL pointer check. However, > > the question still stands do we want everyone to run numbers to > > justify this optimization, or make it a new common kernel coding > > practice to do: > > > > if (!object->op) > > generic_op(object); > > else > > object->op(object); > > > > ...in hot paths? > > I don't think nvdimm_flush is a hot path. Numbers of some > representative workload would prove one of us right. I'd rather say that the if "if (!op) do_generic()" pattern is more readable in the general case, saves grepping for who set the op in the common case. The fact that it has the potential to be faster is gravy at that point. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm