From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5DFAC10F11 for ; Mon, 22 Apr 2019 20:06:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 908BA20643 for ; Mon, 22 Apr 2019 20:06:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="MZnMJSvs" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732284AbfDVUGP (ORCPT ); Mon, 22 Apr 2019 16:06:15 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:40354 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729489AbfDVToc (ORCPT ); Mon, 22 Apr 2019 15:44:32 -0400 Received: by mail-oi1-f194.google.com with SMTP id f196so9361013oib.7 for ; Mon, 22 Apr 2019 12:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=be6f2f0XIlqFU7RHgEDNHdFLaZKAoDs5ON2xf3GreVs=; b=MZnMJSvszGOJ69yW2f92BRR2//4YgYRkKKac5Gqy7Awh1bsWzu6rOOSWtZwJtx/tcG eDw1eDkllfmunatVZlfYdB6E/H0sEhYx56nkD9/3BTyiQhK1cK3ohxtnncyN808QU9Ip EHjb1faIflXV5qJO4U85TcW+zBgo6JUqMcJpYrNghYuo1YIWP/jnyZ0my2UTfw52gR0p 0x1xVJYtgpLLMZiiVV2/R/giaXcjlq2VvA7Z8shcCNAngnJ6VI6G+ScfLPtwzKJEy1HA MzWZ1/YUvj5/eXdhJA+Ieta7O8ADe/tnz1YT0d9DikYe3aJrHMlfOTBTM/lY7uViDVxI lLQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=be6f2f0XIlqFU7RHgEDNHdFLaZKAoDs5ON2xf3GreVs=; b=OzOZ9PRagZ8m9U4i0tsIivEIuR0bOx7GJp5uKaiUrBTTf4wqKYnGeuHj0PFYbG09rY 4G01hgwe5cb5vymgjGIlraZnIOZon3Y+iGs/U6g+uL0mQF9J6z6rIOrw5q+p02HpKs6q 0etwyKaYZkyLvV2dvVHjNF2Z+XEOVysnmxMb2F12nRWb03ws4LhHIc2hDi/Ar8RsyvgV LWKaoCQ0ZkINkp+D43zgCskFxDCdaRh9fNew548r1K4qJ9lAB7axoavStN4yFBEQuWoA 7e/8RXyLAPUZsjqbbnd7to+BRspSyPaLuH+5XvduBNL7WNqSi+u84IN7lSc9GYiAzDVV UhSQ== X-Gm-Message-State: APjAAAXT8g4WcdfENX+JmACLdzrkSMVx4b7+h5RutLEbXXnNwM28C34d LM0JBcR6zLlhMEhvcIUXTh4L8HXeBwHTBQLYCTzh3g== X-Google-Smtp-Source: APXvYqy9oEwsfMU6Hmi4yVBnW8LZ4gUZmwS+KAWSnUmv484C2kN850KPfxFBG55AG8ix9yht3mk81r/aARykAzdCsRE= X-Received: by 2002:aca:f581:: with SMTP id t123mr11818692oih.0.1555962272101; 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 To: Jeff Moyer Cc: Christoph Hellwig , Jan Kara , Pankaj Gupta , linux-nvdimm , Linux Kernel Mailing List , virtualization@lists.linux-foundation.org, KVM list , linux-fsdevel , Linux ACPI , Qemu Developers , linux-ext4 , linux-xfs , Ross Zwisler , Vishal L Verma , Dave Jiang , "Michael S. Tsirkin" , Jason Wang , Matthew Wilcox , "Rafael J. Wysocki" , Len Brown , "Theodore Ts'o" , Andreas Dilger , "Darrick J. Wong" , lcapitulino@redhat.com, Kevin Wolf , Igor Mammedov , Nitesh Narayan Lal , Rik van Riel , Stefan Hajnoczi , Andrea Arcangeli , David Hildenbrand , david , cohuck@redhat.com, Xiao Guangrong , Paolo Bonzini , kilobyte@angband.pl, yuval shaia Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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.