Re: [GIT PULL] Fsnotify cleanups

[Linus Torvalds <torvalds@linux-foundation.org>]

On Fri, Jun 8, 2018 at 6:27 AM Jan Kara <jack@suse.cz> wrote:
>
> The alignment could be fixed by having
>
> struct inode {
>         ...
>         struct fsnotify_obj i_fsnotify __attribute__ ((aligned(sizeof(void *))));
>         ...
> }
>
> but that's too ugly even for my twisted taste. And before someone asks,
> adding aligned attribute to the definition of fsnotify_obj structure makes
> it grow the padding at the end again.

Yeah, I don't think there's any way to say "this can't be an array
member, don't pad the size out to the alignment".

I do wonder if perhaps "struct fsnotify_obj" could actually have a
mask and a 32-bit object ID instead, which would (a) avoid the
alignment issue and (b) actually shrink the structure onm 64-bit.

Obviously you'd then have to look up the pointer from the object ID
(presumably using a hash, but maybe it would use the radix tree of
idr_alloc() or something).

I haven't looked at how often those pointers actually get looked up.
If the 'mask' makes it fairly rare, then the extra indirection might
be ok. I suspect it's not. But I thought I'd mention it as a possible
approach.

The other approach is - as you say - to move 'mask' to be behind the
pointer. But if that causes a lot of extra pointer chasing that mask
would normally avoid, that could be really expensive too. We see that
with the security objects: the cost of looking up whatever is behind
i_security is really nasty, because every inode gets allocated a
private security structure, so it's absolutely horrendous for cache
effects (no sharing).

But I suspect that the behavior of i_fsnotify_marks is very different
from i_security, in that most inodes probably don't have marks at all.
No? Yes? So you might not have the nasty case of "almost all inode
access ends up following that pointer and it's horrible in the cache".

                  Linus