why this field is taskstats. ac_sched is specifically aligned as 8?

why this field is taskstats. ac_sched is specifically aligned as 8?

[Shiyao MA]

Hi,

http://elixir.free-electrons.com/linux/latest/source/include/uapi/linux/taskstats.h#L107

Why the field is taskstats. ac_sched aligned as 8 ?

-- 
Best,
Shiyao

why this field is taskstats. ac_sched is specifically aligned as 8?

[Greg KH]

On Fri, Dec 15, 2017 at 08:16:45PM +0800, Shiyao MA wrote:
> Hi,
> 
> http://elixir.free-electrons.com/linux/latest/source/include/uapi/linux/taskstats.h#L107
> 
> Why the field is taskstats. ac_sched aligned as 8 ?

Think about the field layout in memory if that variable was _not_
aligned as 8.  What would happen to accessing all of the variables after
that in the structure?  Would that work as efficiently?

Memory layout matters on structures that are accessed very frequently :)

hope this helps,

greg k-h

why this field is taskstats. ac_sched is specifically aligned as 8?

[Shiyao MA]

Hi greg,

I take a snapshot of the fields here.

>> /* Basic Accounting Fields start */
>> char ac_comm[TS_COMM_LEN]; /* Command name */
>> __u8 ac_sched __attribute__((aligned(8)));
>> /* Scheduling discipline */
>> __u8 ac_pad[3];

After ac_sched is ac_pad, which is just padding.  I still can't
understand the meaning of impose an alignment of 8 on ac_sched.

>> __u32 ac_uid __attribute__((aligned(8)));
>> /* User ID */
>> __u32 ac_gid; /* Group ID */
>> __u32 ac_pid; /* Process ID */

Because we have a =aligned(8)= on ac_uid, so the alignment in
=ac_sched= does not affect variables here and after.
by default _u32 has alignment has 4, why enforce 8 here?   Is it
because we need a mov64-like instruction that takes ac_uid and ac_gid
together?  still a weird reason though.


-- 
Best,
Shiyao