From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f194.google.com ([209.85.223.194]:35920 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752971AbeFHUeQ (ORCPT ); Fri, 8 Jun 2018 16:34:16 -0400 Received: by mail-io0-f194.google.com with SMTP id k3-v6so3283165iog.3 for ; Fri, 08 Jun 2018 13:34:16 -0700 (PDT) MIME-Version: 1.0 References: <20180607150217.jq757ncqopuimbkd@quack2.suse.cz> <20180608132737.etbkpqg77yz3vhp7@quack2.suse.cz> In-Reply-To: <20180608132737.etbkpqg77yz3vhp7@quack2.suse.cz> From: Linus Torvalds Date: Fri, 8 Jun 2018 13:34:04 -0700 Message-ID: Subject: Re: [GIT PULL] Fsnotify cleanups To: Jan Kara Cc: linux-fsdevel , Amir Goldstein Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Jun 8, 2018 at 6:27 AM Jan Kara 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