Messages in this thread | | | From | Jeff Moyer <> | Subject | Re: [PATCH v5 1/6] libnvdimm: nd_region flush callback support | Date | Thu, 18 Apr 2019 12:10:44 -0400 |
| |
Dan Williams <dan.j.williams@intel.com> writes:
> On Fri, Apr 12, 2019 at 6:12 AM Jeff Moyer <jmoyer@redhat.com> wrote: >> >> Jan Kara <jack@suse.cz> writes: >> >> > On Thu 11-04-19 07:51:48, Dan Williams wrote: >> >> On Tue, Apr 9, 2019 at 9:09 PM Pankaj Gupta <pagupta@redhat.com> wrote: >> >> > + } else { >> >> > + if (nd_region->flush(nd_region)) >> >> > + rc = -EIO; >> >> >> >> Given the common case wants to be fast and synchronous I think we >> >> should try to avoid retpoline overhead by default. So something like >> >> this: >> >> >> >> if (nd_region->flush == generic_nvdimm_flush) >> >> rc = generic_nvdimm_flush(...); >> > >> > 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/
The technique is fine, but that doesn't mean it should be applied everywhere. Is *this* code path really going to benefit from the optimization?
-Jeff
| |