Received: by 2002:a05:6520:4211:b029:f4:110d:56bc with SMTP id o17csp1312340lkv; Thu, 29 Apr 2021 03:08:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzqURBGfeOtEgMtMVr9A7RwPKFKA/jhmhmxz7a6f2JqsRrAUA3NzPZW4e1dLVdcqzHVEFZn X-Received: by 2002:a17:902:bc88:b029:ee:7ef1:e770 with SMTP id bb8-20020a170902bc88b02900ee7ef1e770mr1303092plb.19.1619690927926; Thu, 29 Apr 2021 03:08:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619690927; cv=none; d=google.com; s=arc-20160816; b=OH4HWO//H/5ICtSeDebMrtdHJJnZiI6CweSNcdnd+Q1khPGgdqK7zc3szR80O7swE1 7qZjeaky+sA38cmSHkSm6Wtfmgf7mglgMetsTMhZs9+Pn3PFet72+PxEqEods0bbN+Kf dsCwFWJ1rwF5kobe7XqoZRawf4hUuJCdH4qoJJ1SrkB1NLwOr/KSSfXGaOirzgqrl0mw y/JHDaezEJ48Va47K1JOO/mtUG3ko5GlCz1tU1ynEQiKswD3RVk87+ThOXx7RPNOGEkz FuWbh00qcwjPrmj0cZ17jLiujKi9x0hOZRNKF1vulBGIjNy/FKq8QZUNiaLo22HfSEsG X7HA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=MA+Z2vBu+kQxsAUi531Ida4eNEldjywgPfjg69xC1rs=; b=UowfinrvWqtRThLW1NVNsWSAHSOqipDeDUXXztDbfAAuFy02mky2skoxf52uCoKm8d FwGNoKSEQYm7tKMp/QrCYytKwk3e+W47mpKKGcMEIci75wFUAMAdatsYubSYlscWhinO RHMPHClkl/EOIZ72/fGJ2lrru2X1n8kX5XJoksfGGp0j328Vq+4fsZCDR+IxNVfj6sHb 2dNP3Kpo6zl0u9LVKyfn/cSqvVa4lkVOta1J9gPF+mKmYJEnQTvP9f4dhtDoCwsk+OMd 4aHw81Jwt0SI2HXlwWqr6GkkBiGzWYeS2pS2zpdKVA+Dq23blu5bk8+K/L777NBGKPYM QXMg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z2si3359877pgu.156.2021.04.29.03.08.34; Thu, 29 Apr 2021 03:08:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233219AbhD2KGx (ORCPT + 99 others); Thu, 29 Apr 2021 06:06:53 -0400 Received: from mx2.suse.de ([195.135.220.15]:33010 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231543AbhD2KGw (ORCPT ); Thu, 29 Apr 2021 06:06:52 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 87C1CAF8C; Thu, 29 Apr 2021 10:06:05 +0000 (UTC) Subject: Re: [PATCH -next] bcache: use DEFINE_MUTEX() for mutex lock To: Muhammad Usama Anjum , Zheng Yongjun , Kent Overstreet , Dan Carpenter Cc: linux-bcache@vger.kernel.org, kernel-janitors@vger.kernel.org, Hulk Robot , linux-kernel References: <20210405101453.15096-1-zhengyongjun3@huawei.com> <42c3e33d-c20e-0fdd-f316-5084e33f9a3b@suse.de> <0b4b7c5cc2f19d2d77a66c0d2ce42f63692174d9.camel@gmail.com> From: Coly Li Message-ID: Date: Thu, 29 Apr 2021 18:05:56 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <0b4b7c5cc2f19d2d77a66c0d2ce42f63692174d9.camel@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/29/21 12:19 AM, Muhammad Usama Anjum wrote: > On Tue, 2021-04-06 at 02:17 +0500, Muhammad Usama Anjum wrote: >> On Mon, 2021-04-05 at 22:02 +0800, Coly Li wrote: >>> On 4/5/21 6:14 PM, Zheng Yongjun wrote: >>>> mutex lock can be initialized automatically with DEFINE_MUTEX() >>>> rather than explicitly calling mutex_init(). >>>> >>>> Reported-by: Hulk Robot >>>> Signed-off-by: Zheng Yongjun >>> >>> NACK. This is not the first time people try to "fix" this location... >>> >>> Using DEFINE_MUTEX() does not gain anything for us, it will generate >>> unnecessary extra size for the bcache.ko. >>> ines. >> >> How can the final binary have larger size by just static declaration? >> By using DEFINE_MUTEX, the mutex is initialized at compile time. It'll >> save initialization at run time and one line of code will be less also >> from text section. >> >> #### with no change (dynamic initialization) >> size drivers/md/bcache/bcache.ko >> text data bss dec hex filename >> 187792 25310 152 213254 34106 drivers/md/bcache/bcache.ko >> >> #### with patch applied (static initialization) >> text data bss dec hex filename >> 187751 25342 120 213213 340dd drivers/md/bcache/bcache.ko >> >> Module's binary size has decreased by 41 bytes with the path applied >> (x86_64 arch). >> > Anybody has any thoughts on it? > > I am waiting for Yongjun's v4 patch to update the commit log, which was suggested by Pavel Goran. Coly Li