Received: by 10.192.165.156 with SMTP id m28csp359909imm; Wed, 18 Apr 2018 23:50:07 -0700 (PDT) X-Google-Smtp-Source: AIpwx48sY4ycG+H5jl3amLSFzj9FmMmV3HybPbw3RTsoeC2KHAXq7+ztqyT+kjCEoKkoE/McpuxK X-Received: by 10.101.97.1 with SMTP id z1mr4263688pgu.134.1524120607367; Wed, 18 Apr 2018 23:50:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524120607; cv=none; d=google.com; s=arc-20160816; b=LZQY3AqowsPOkWNpRDCIGCRMfvxPP5/PzViaRUUYbDqpMSJ7HR291mJomxSDmgiywd 3Vsj63hPAWAKbsCBH/ZS9xZfvM2yAv4NxhVKCVVPsTTTZnmI6C+9dg8l8fAGCxFYu/KB vJDNnW9TpHPHS5iSfAa1iWT9FYj/ztfA8JQ8phl21dvRoBHkrIi4zBlCDWVurJX6W4a8 tCWiEvJcrkzK1zq+kWsXk4O30ECqEVbzQIDRLIp4EkUcX42ISZaCfkEC3fJYY8UjCuC0 a2TxMI9Pge+gpDCOo9xIc5TiU03adkQhVsQXTdyep+VpESpkEsK9379mIafoTyn2EVSL ktUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=mDv6vKrA1RxW8jW78BhSDud7o2l1VfHFxnndn8pSuyk=; b=GksJOoIgCnh1h7B5pT3GgGVn7ktOXyLpiKhF9nPMtqXAOZigdbagRpXGSrRv2zrOre blhiL2jQ4+XI7QZLontykvz/EKCIHCD/2OlqK1QxIZIo/+iQtDmMQRIZuJrk7TW/LZAz rM4qS33hIB32bgG+X0BORHqYlEg7yHI1TMymZ9o12pgwmIIaG0ArbWp9RhMq28vRn0EO J+lwwMnfeq7JsIn7byWSYgErVcm7oNAeU6P+QJMntlmiFCxxAWRoh8bs4f97EnoaNMlm W1Fp8UlvRLoLvPCd9VViIgk80NLA9J9fXv7HY3eG9d7rz8SdxQm1n3Vwtj2ntY/GycYR E56w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=BPjRhB3F; dkim=pass header.i=@codeaurora.org header.s=default header.b=PK6pITrd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d6-v6si2762332plo.551.2018.04.18.23.49.53; Wed, 18 Apr 2018 23:50:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=BPjRhB3F; dkim=pass header.i=@codeaurora.org header.s=default header.b=PK6pITrd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752028AbeDSGsq (ORCPT + 99 others); Thu, 19 Apr 2018 02:48:46 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:54286 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751005AbeDSGso (ORCPT ); Thu, 19 Apr 2018 02:48:44 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 3330D60C5F; Thu, 19 Apr 2018 06:48:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1524120524; bh=79QHKmnRqp9YFC3mQvgmaiOlcijdFmcsU/DlNzUn7vw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=BPjRhB3FYnPyTEjMu4fi4QPtfPh2DGUkgsL3zm/EgWj8ohUD02YpdqXpCgZqedu6e ean2ju8gUsUzw16QtuK1zoEg/394Vdkq4os8U989zJ7cUsKZX9zNLgcwekkvry/EKq 2EdXNRLc3558PSqfYnIujtVGryeq1WbHde9MeQxw= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id AC66E601CF; Thu, 19 Apr 2018 06:48:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1524120522; bh=79QHKmnRqp9YFC3mQvgmaiOlcijdFmcsU/DlNzUn7vw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=PK6pITrdcXxM3Dm4z9IVzKn4pvuuu0uM4jGRC5KBxky6JDtH9avbayEMy6blqah9K v5hbdHKfLoj1tQYqwvIMcmIavouxNFPEAqNtLkOvT0vTOPaiGiqqkSKnQLXcSI6lBO Y1yYLTTMkcWvBebvKVUntGGnXdDzBTZUF8hwVyHM= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 19 Apr 2018 14:48:42 +0800 From: yuankuiz@codeaurora.org To: Julia Lawall Cc: Joe Perches , Andrew Morton , Peter Zijlstra , "Rafael J. Wysocki" , Andy Whitcroft , Linux PM , "Rafael J. Wysocki" , Frederic Weisbecker , Thomas Gleixner , paulmck@linux.vnet.ibm.com, Ingo Molnar , Len Brown , Linux Kernel Mailing List , linux-pm-owner@vger.kernel.org Subject: Re: [PATCH] checkpatch: Add a --strict test for structs with bool member definitions In-Reply-To: References: <891d4f632fbff5052e11f2d0b6fac35d@codeaurora.org> <20180410123305.GF4082@hirez.programming.kicks-ass.net> <95477c93db187bab6da8a8ba7c57836868446179.camel@perches.com> <20180410143950.4b8526073b4e3e34689f68cb@linux-foundation.org> <20180410150011.df9e036f57b5bcac7ac19686@linux-foundation.org> <20180411081502.GJ4082@hirez.programming.kicks-ass.net> <20180411092959.e666ec443e4d3bb6f43901d7@linux-foundation.org> <1c9f185f6086e9d89659f93720a27b660ee17c13.camel@perches.com> <5341b3b1945c4c1dbf7b356b1a7a4bd6ce304287.camel@perches.com> Message-ID: <473cf88b25731a3729a3566abbebd0b6@codeaurora.org> X-Sender: yuankuiz@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-04-19 01:16 PM, Julia Lawall wrote: > On Wed, 18 Apr 2018, Joe Perches wrote: > >> On Thu, 2018-04-19 at 06:40 +0200, Julia Lawall wrote: >> > >> > On Wed, 18 Apr 2018, Joe Perches wrote: >> > >> > > On Tue, 2018-04-17 at 17:07 +0800, yuankuiz@codeaurora.org wrote: >> > > > Hi julia, >> > > > >> > > > On 2018-04-15 05:19 AM, Julia Lawall wrote: >> > > > > On Wed, 11 Apr 2018, Joe Perches wrote: >> > > > > >> > > > > > On Thu, 2018-04-12 at 08:22 +0200, Julia Lawall wrote: >> > > > > > > On Wed, 11 Apr 2018, Joe Perches wrote: >> > > > > > > > On Wed, 2018-04-11 at 09:29 -0700, Andrew Morton wrote: >> > > > > > > > > We already have some 500 bools-in-structs >> > > > > > > > >> > > > > > > > I got at least triple that only in include/ >> > > > > > > > so I expect there are at probably an order >> > > > > > > > of magnitude more than 500 in the kernel. >> > > > > > > > >> > > > > > > > I suppose some cocci script could count the >> > > > > > > > actual number of instances. A regex can not. >> > > > > > > >> > > > > > > I got 12667. >> > > > > > >> > > > > > Could you please post the cocci script? >> > > > > > >> > > > > > > I'm not sure to understand the issue. Will using a bitfield help if there >> > > > > > > are no other bitfields in the structure? >> > > > > > >> > > > > > IMO, not really. >> > > > > > >> > > > > > The primary issue is described by Linus here: >> > > > > > https://lkml.org/lkml/2017/11/21/384 >> > > > > > >> > > > > > I personally do not find a significant issue with >> > > > > > uncontrolled sizes of bool in kernel structs as >> > > > > > all of the kernel structs are transitory and not >> > > > > > written out to storage. >> > > > > > >> > > > > > I suppose bool bitfields are also OK, but for the >> > > > > > RMW required. >> > > > > > >> > > > > > Using unsigned int :1 bitfield instead of bool :1 >> > > > > > has the negative of truncation so that the uint >> > > > > > has to be set with !! instead of a simple assign. >> > > > > >> > > > > At least with gcc 5.4.0, a number of structures become larger with >> > > > > unsigned int :1. bool:1 seems to mostly solve this problem. The >> > > > > structure >> > > > > ichx_desc, defined in drivers/gpio/gpio-ich.c seems to become larger >> > > > > with >> > > > > both approaches. >> > > > >> > > > [ZJ] Hopefully, this could make it better in your environment. >> > > > IMHO, this is just for double check. >> > > >> > > I doubt this is actually better or smaller code. >> > > >> > > Check the actual object code using objdump and the >> > > struct alignment using pahole. >> > >> > I didn't have a chance to try it, but it looks quite likely to result in a >> > smaller data structure based on the other examples that I looked at. >> >> I _really_ doubt there is any difference in size between the >> below in any architecture >> >> struct foo { >> int bar; >> bool baz:1; >> int qux; >> }; >> >> and >> >> struct foo { >> int bar; >> bool baz; >> int qux; >> }; >> >> Where there would be a difference in size is >> >> struct foo { >> int bar; >> bool baz1:1; >> bool baz2:1; >> int qux; >> }; >> >> and >> >> struct foo { >> int bar; >> bool baz1; >> bool baz2; >> >> int qux; >> }; > > In the situation of the example there are two bools together in the > middle > of the structure and one at the end. Somehow, even converting to > bool:1 > increases the size. But it seems plausible that putting all three > bools > together and converting them all to :1 would reduce the size. I don't > know. The size increase (more than 8 bytes) seems out of proportion > for 3 > bools. [ZJ] Typically, addition saving is due for difference padding. > > I was able to check around 3000 structures that were not declared with > any > attributes, that don't declare named types internally, and that are > compiled for x86. Around 10% become smaller whn using bool:1, > typically > by at most 8 bytes. > > julia > >> >>