Re: [PATCH 1/2] device.h: pack struct dev_links_info

[Greg Kroah-Hartman]

On Wed, Feb 27, 2019 at 10:40:21AM +0100, Johan Hovold wrote:
> On Wed, Feb 27, 2019 at 10:31:04AM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Feb 27, 2019 at 10:23:18AM +0100, Johan Hovold wrote:
> > > On Tue, Feb 26, 2019 at 03:41:07PM +0100, Greg Kroah-Hartman wrote:
> > > > The dev_links_info structure has 4 bytes of padding at the end of it
> > > > when embedded in struct device (which is the only place it lives).  To
> > > > help reduce the size of struct device pack this structure so we can take
> > > > advantage of the hole with later structure reorganizations.
> > > > 
> > > > Cc: "Rafael J. Wysocki" <rafael.j.wysocki@xxxxxxxxx>
> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> > > > ---
> > > >  include/linux/device.h | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/include/linux/device.h b/include/linux/device.h
> > > > index 6cb4640b6160..b63165276a09 100644
> > > > --- a/include/linux/device.h
> > > > +++ b/include/linux/device.h
> > > > @@ -884,7 +884,7 @@ struct dev_links_info {
> > > >  	struct list_head suppliers;
> > > >  	struct list_head consumers;
> > > >  	enum dl_dev_state status;
> > > > -};
> > > > +} __packed;
> > > 
> > > This seems like a bad idea. You're changing the alignment of these
> > > fields to one byte, something which may cause the compiler to generate
> > > less efficient code to deal with unaligned accesses (even if they happen
> > > to currently be naturally aligned in struct device).
> > 
> > No, all this changes is the trailing "space" is gone.  The alignment of
> > the fields did not change at all as they are all naturally aligned
> > (list_head is just 2 pointers).
> 
> Yes, currently and in struct device, but given a pointer to a struct
> dev_links_info the compiler must assume it is unaligned and act
> accordingly for example.

Packing the structure doesn't mean that the addressing of it is not also
aligned, that should just depend on the location of the pointer in the
first place, right?

Surely compilers are not that foolish :)

And accessing this field should not be an issue of "slow", hopefully the
memory savings would offset any compiler mess.

> > So this allows us to save 4 bytes in struct device by putting something in that
> > trailing "hole" that can be aligned with it better (i.e. an integer or
> > something else).
> 
> I understand that, but I don't think it is worth to start using packed
> liked this for internal structures as it may have subtle and unintended
> consequences.

I'm not understanding what the consequences are here, sorry.  Does the
compiler output change given that the structure is still aligned
properly in the "parent" structure?  I can't see any output changed
here, but maybe I am not looking properly?

thanks,

greg k-h