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=DKIM_SIGNED,DKIM_VALID, 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 736A1C43331 for ; Mon, 30 Mar 2020 06:52:17 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F3C6020774 for ; Mon, 30 Mar 2020 06:52:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="ff104ocL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F3C6020774 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=SDF.ORG Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 4B098886; Mon, 30 Mar 2020 08:51:25 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 4B098886 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1585551135; bh=W3dzEVQwy4kN8V2y2/86lHamXuEpKOABwF7N97AVg58=; h=Date:From:To:Subject:References:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=ff104ocL6l0GKTsYEH29/cnj1WgthzcRTGq/wE+i4D3YMhU+Nx2rMuxWVtWBpxAhy FoKFXJ13lCcqfuD0fGvlo0URRnTLDKatmQ0z50ZOieWCVQQP34qfy+6KiihcbXQjYa FsVWbMcCkEJOczTYns9t0mzf48IEj2/qQewlPlsk= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id BC093F8010C; Mon, 30 Mar 2020 08:51:24 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 87D3BF8010C; Mon, 30 Mar 2020 08:51:22 +0200 (CEST) Received: from mx.sdf.org (mx.sdf.org [205.166.94.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 712C4F8010C for ; Mon, 30 Mar 2020 08:51:14 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 712C4F8010C Received: from sdf.org (IDENT:lkml@sdf.lonestar.org [205.166.94.16]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 02U6p8D4025450 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 30 Mar 2020 06:51:08 GMT Received: (from lkml@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 02U6p5rX014028; Mon, 30 Mar 2020 06:51:05 GMT Date: Mon, 30 Mar 2020 06:51:05 +0000 From: George Spelvin To: Takashi Iwai Subject: Re: [RFC PATCH v1 13/50] Avoid some useless msecs/jiffies conversions Message-ID: <20200330065105.GB9333@SDF.ORG> References: <202003281643.02SGhBrh000992@sdf.org> <20200329121129.GC11951@SDF.ORG> <20200329175032.GE4675@SDF.ORG> <1585505807.4510.1.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: lkml@sdf.org, alsa-devel@alsa-project.org, Marek Lindner , linux-scsi@vger.kernel.org, Simon Wunderlich , linux-wireless@vger.kernel.org, Takashi Iwai , Antonio Quartulli , linux-kernel@vger.kernel.org, James Bottomley , b.a.t.m.a.n@diktynna.open-mesh.org, Hannes Reinecke , Johannes Berg , Sven Eckelmann X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" 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! > 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. I assumed that open-coding x * HZ was the preferred style, so that's what I did. 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 940A8C43331 for ; Mon, 30 Mar 2020 06:56:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 728FF20774 for ; Mon, 30 Mar 2020 06:56:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729313AbgC3G4j (ORCPT ); Mon, 30 Mar 2020 02:56:39 -0400 Received: from mx.sdf.org ([205.166.94.20]:65413 "EHLO mx.sdf.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729099AbgC3G4j (ORCPT ); Mon, 30 Mar 2020 02:56:39 -0400 Received: from sdf.org (IDENT:lkml@sdf.lonestar.org [205.166.94.16]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 02U6p8D4025450 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 30 Mar 2020 06:51:08 GMT Received: (from lkml@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 02U6p5rX014028; Mon, 30 Mar 2020 06:51:05 GMT Date: Mon, 30 Mar 2020 06:51:05 +0000 From: George Spelvin To: Takashi Iwai 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 Message-ID: <20200330065105.GB9333@SDF.ORG> References: <202003281643.02SGhBrh000992@sdf.org> <20200329121129.GC11951@SDF.ORG> <20200329175032.GE4675@SDF.ORG> <1585505807.4510.1.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org 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! > 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. I assumed that open-coding x * HZ was the preferred style, so that's what I did.