linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Himanshu Jha <himanshujha199640@gmail.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>,
	Amir Mahdi Ghorbanian <indigoomega021@gmail.com>,
	lars@metafoo.de, Michael.Hennerich@analog.com, knaack.h@gmx.de,
	pmeerw@pmeerw.net, gregkh@linuxfoundation.org,
	linux-iio@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Staging: iio: ad7192: replaced bool in struct
Date: Sat, 12 Jan 2019 16:59:38 +0000	[thread overview]
Message-ID: <20190112165938.0a7baa50@archlinux> (raw)
In-Reply-To: <20190107175748.GA29220@himanshu-Vostro-3559>

On Mon, 7 Jan 2019 23:27:48 +0530
Himanshu Jha <himanshujha199640@gmail.com> wrote:

> On Wed, Jan 02, 2019 at 01:25:27PM -0800, Matt Ranostay wrote:
> >   
> > > On Dec 24, 2018, at 01:58, Himanshu Jha <himanshujha199640@gmail.com> wrote:
> > >   
> > >> On Fri, Dec 21, 2018 at 03:26:26PM -0800, Amir Mahdi Ghorbanian wrote:
> > >> Replaced bool in struct with unsigned int bitfield to conserve space and
> > >> more clearly define size of varibales  
> > 
> > Important thing to note is depending on padding, alignment, and position of field it probably won’t save any space.  
> 
> Well, then what do you say about the following results ;-)
> 
> Before:
> ------
> 
> himanshu@himanshu-Vostro-3559:~/gsoc/linux$ pahole -C ad7192_platform_data drivers/staging/iio/adc/ad7192.o
> struct ad7192_platform_data {
> 	u16                        vref_mv;              /*     0     2 */
> 	u8                         clock_source_sel;     /*     2     1 */
> 
> 	/* XXX 1 byte hole, try to pack */
> 
> 	u32                        ext_clk_hz;           /*     4     4 */
> 	bool                       refin2_en;            /*     8     1 */
> 	bool                       rej60_en;             /*     9     1 */
> 	bool                       sinc3_en;             /*    10     1 */
> 	bool                       chop_en;              /*    11     1 */
> 	bool                       buf_en;               /*    12     1 */
> 	bool                       unipolar_en;          /*    13     1 */
> 	bool                       burnout_curr_en;      /*    14     1 */
> 
> 	/* size: 16, cachelines: 1, members: 10 */
> 	/* sum members: 14, holes: 1, sum holes: 1 */
> 	/* padding: 1 */
> 	/* last cacheline: 16 bytes */
> };
> 
> After:
> -----
> 
> himanshu@himanshu-Vostro-3559:~/gsoc/linux$ pahole -C ad7192_platform_data drivers/staging/iio/adc/ad7192.o
> struct ad7192_platform_data {
> 	u16                        vref_mv;              /*     0     2 */
> 	u8                         clock_source_sel;     /*     2     1 */
> 
> 	/* XXX 1 byte hole, try to pack */
> 
> 	u32                        ext_clk_hz;           /*     4     4 */
> 	unsigned int               refin2_en:1;          /*     8:31  4 */
> 	unsigned int               rej60_en:1;           /*     8:30  4 */
> 	unsigned int               sinc3_en:1;           /*     8:29  4 */
> 	unsigned int               chop_en:1;            /*     8:28  4 */
> 	unsigned int               buf_en:1;             /*     8:27  4 */
> 	unsigned int               unipolar_en:1;        /*     8:26  4 */
> 	unsigned int               burnout_curr_en:1;    /*     8:25  4 */
> 
> 	/* size: 12, cachelines: 1, members: 10 */
> 	/* sum members: 11, holes: 1, sum holes: 1 */
> 	/* bit_padding: 25 bits */
> 	/* last cacheline: 12 bytes */
> };
> 
> > Also for internal unpacked structures it really makes little sense to save a few bytes of data. Don’t read into that packed structures are good.. they usually aren’t :)  
> 
> Yes, agreed, but I often see patches to save few bytes by marking
> array as static.
> 
> There is some effort in this direction:
> https://lore.kernel.org/lkml/20181221235230.GC13168@ziepe.ca/
> 
> Very likely to get more patches if the above patch gets merged.
> 
The one additional thing that is relevant here is that we will probably
drop the whole structure anyway as part of moving it out of staging.
There might be some equivalent elements stored elsewhere, but quite
likely it won't be all of them.  As a result I'm not particularly keen
on patches to clean platform data up.

+ we really are dealing with trivial amounts of data here..

J

  reply	other threads:[~2019-01-12 16:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-21 23:26 [PATCH] Staging: iio: ad7192: replaced bool in struct Amir Mahdi Ghorbanian
2018-12-22 17:28 ` Jonathan Cameron
2018-12-24  9:58 ` Himanshu Jha
2019-01-02 21:25   ` Matt Ranostay
2019-01-07 17:57     ` Himanshu Jha
2019-01-12 16:59       ` Jonathan Cameron [this message]
2019-01-02 11:33 ` Dan Carpenter
     [not found] <CAMW2b-maU7+WrwYnqqr7eUVw+S_MC9_do27ms-or8wWDapbqZA@mail.gmail.com>
2019-01-05 18:22 ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190112165938.0a7baa50@archlinux \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=himanshujha199640@gmail.com \
    --cc=indigoomega021@gmail.com \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt.ranostay@konsulko.com \
    --cc=pmeerw@pmeerw.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).