Re: [PATCH 1/3] btrfs: simplify WQ_HIGHPRI handling in struct btrfs_workqueue

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2022/4/23 05:05, David Sterba wrote:
> On Mon, Apr 18, 2022 at 04:03:43PM +0800, Qu Wenruo wrote:
>>> -struct __btrfs_workqueue {
>>> +struct btrfs_workqueue {
>>>    	struct workqueue_struct *normal_wq;
>>
>> I guess we can also rename @normal_wq here, as there is only one wq in
>> each btrfs_workqueue, no need to distinguish them in btrfs_workqueue.
>
> Yeah now the 'normal_' prefix does not make sense.
>
>> And since we're here, doing a pahole optimization would also be a good
>> idea (can be done in a sepearate patchset).
>>
>> Especially there is a huge 16 bytes hole between @ordered_list and
>> @list_lock.
>
> On a release build the packing is good, I don't see any holes there:

Oh, I'm using debug builds, no wonder.

Just by my pure curiosity, there seems to be some topic on randomizing
kernel structures (definitely not all, that would not only screw up
on-disk format but also various interface).

But for structures only used inside one module, and not exposed, is
there any attribute to allow compiler to do the optimization at runtime?

Thanks,
Qu
>
> struct btrfs_work {
>          btrfs_func_t               func;                 /*     0     8 */
>          btrfs_func_t               ordered_func;         /*     8     8 */
>          btrfs_func_t               ordered_free;         /*    16     8 */
>          struct work_struct         normal_work;          /*    24    32 */
>          struct list_head           ordered_list;         /*    56    16 */
>          /* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */
>          struct btrfs_workqueue *   wq;                   /*    72     8 */
>          long unsigned int          flags;                /*    80     8 */
>
>          /* size: 88, cachelines: 2, members: 7 */
>          /* last cacheline: 24 bytes */
> };
>
> The fs_info structure grew a bit but it's a large one and there's still
> enough space before it hits 4K.