On Wed, 29 Jun 2016 11:38:37 +0900
Namhyung Kim wrote:
> Ok then, I'll change it to use 'packed' only in v3.
>
I would add a comment that the structure is already packed and that the
"packed" attribute is just to remove the extra padding at the end of
the struct.
-- Steve
On Tue, Jun 28, 2016 at 09:57:38PM -0400, Steven Rostedt wrote:
> On Wed, 29 Jun 2016 10:32:34 +0900
> Namhyung Kim wrote:
>
> > > is at 32-37
> > >
> > > For a total of 38 bytes. I'm betting that without the packed, the 4
> > > extra bytes will always be at the end.
> >
> > Woundn't it be 36
On Wed, 29 Jun 2016 10:32:34 +0900
Namhyung Kim wrote:
> > is at 32-37
> >
> > For a total of 38 bytes. I'm betting that without the packed, the 4
> > extra bytes will always be at the end.
>
> Woundn't it be 36 or 40 bytes? :)
Ug, don't know what I was counting then. I added the 64 bit vers
On Tue, Jun 28, 2016 at 07:32:00PM -0400, Steven Rostedt wrote:
> On Tue, 28 Jun 2016 14:30:40 +0900
> Namhyung Kim wrote:
>
> > Currently ftrace_graph_ent{,_entry} and ftrace_graph_ret{,_entry} struct
> > can have padding bytes at the end due to alignment in 64-bit data type.
> > As these data a
On Tue, 28 Jun 2016 14:30:40 +0900
Namhyung Kim wrote:
> Currently ftrace_graph_ent{,_entry} and ftrace_graph_ret{,_entry} struct
> can have padding bytes at the end due to alignment in 64-bit data type.
> As these data are recorded so frequently, those paddings waste
> non-negligible space. As
Currently ftrace_graph_ent{,_entry} and ftrace_graph_ret{,_entry} struct
can have padding bytes at the end due to alignment in 64-bit data type.
As these data are recorded so frequently, those paddings waste
non-negligible space. As some archs can have efficient unaligned
accesses, reducing the al
6 matches
Mail list logo
