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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 A4D0DC2D0E9 for ; Mon, 30 Mar 2020 07:29:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 866E920781 for ; Mon, 30 Mar 2020 07:29:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729424AbgC3H3X (ORCPT ); Mon, 30 Mar 2020 03:29:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:35874 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729197AbgC3H3X (ORCPT ); Mon, 30 Mar 2020 03:29:23 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0124DAF48; Mon, 30 Mar 2020 07:29:20 +0000 (UTC) Date: Mon, 30 Mar 2020 09:29:20 +0200 Message-ID: From: Takashi Iwai To: George Spelvin Cc: James Bottomley , linux-kernel@vger.kernel.org, Hannes Reinecke , linux-scsi@vger.kernel.org, Marek Lindner , Simon Wunderlich , Antonio Quartulli , Sven Eckelmann , b.a.t.m.a.n@diktynna.open-mesh.org, Johannes Berg , linux-wireless@vger.kernel.org, Jaroslav Kysela , Takashi Iwai , alsa-devel@alsa-project.org, lkml@sdf.org Subject: Re: [RFC PATCH v1 13/50] Avoid some useless msecs/jiffies conversions In-Reply-To: <20200330065105.GB9333@SDF.ORG> References: <202003281643.02SGhBrh000992@sdf.org> <20200329121129.GC11951@SDF.ORG> <20200329175032.GE4675@SDF.ORG> <1585505807.4510.1.camel@HansenPartnership.com> <20200330065105.GB9333@SDF.ORG> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Mon, 30 Mar 2020 08:51:05 +0200, George Spelvin wrote: > > On Mon, Mar 30, 2020 at 08:27:01AM +0200, Takashi Iwai wrote: > > On Sun, 29 Mar 2020 20:16:47 +0200, James Bottomley wrote: > >> We all assume that msecs_to_jiffies is properly optimized so there > >> should be no need to open code it like you're proposing. > > > > Yes, it'd be best if the compiler can handle it properly. > > I've tried, and can't figure out how to get the compiler to detect this > special case and not invoke the general code. In particular, for a > variable x, __builtin_constant_p(x * 1000 % 1000) is false. Even if x is > signed and ANSI lets the compiler assume that overflow doesn't happen. > > If you can do it, I'm most curious how! Actually in the very early version of msecs_to_jiffies() was all inlined, so the compiler could optimize such a case, I guess. Now it was factored out to an external function in commit ca42aaf0c861, so it became difficult. > > But also I meant to keep using the macro for consistency reason. > > IIRC, we wanted to eliminate the explicit use of HZ in the past, and > > it's how many lines have been converted with *_to_jiffies() calls. > > I don't know whether the eliminate of HZ is still wished, but > > reverting to the open code is a step backward for that. > > Well, you could always add a secs_to_jiffies(x) wrapper. But given > that it expands to basically x * HZ, some people might wonder why > you're bothering. Well, comparing with the expanded result doesn't make always sense. With such a logic, you can argue why BIT(x) macro is needed, too. After all, it's a matter of semantics. > I assumed that open-coding x * HZ was the preferred style, so that's > what I did. That's my question, too -- whether the open code is preferred for this particular purpose. thanks, Takashi