From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:46033 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752804AbeFKQMv (ORCPT ); Mon, 11 Jun 2018 12:12:51 -0400 Date: Mon, 11 Jun 2018 18:12:49 +0200 From: Jan Kara To: Amir Goldstein Cc: Linus Torvalds , Jan Kara , linux-fsdevel Subject: Re: [GIT PULL] Fsnotify cleanups Message-ID: <20180611161249.d3g64fcfuwezlxeq@quack2.suse.cz> References: <20180607150217.jq757ncqopuimbkd@quack2.suse.cz> <20180608132737.etbkpqg77yz3vhp7@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sat 09-06-18 11:00:17, Amir Goldstein wrote: > On Sat, Jun 9, 2018 at 9:57 AM, Amir Goldstein wrote: > > The only code that needs to test the shadow mask before following into > > connector is the optimization code in start of fsnotify() which was not > > generalized anyway and where the mask optimization is more important > > for mount watches. > > > > No. That's not true, there is also fsnotify_inode_watches_children() and > __fsnotify_parent(). But I think the only bits in the mask that really matter > for optimizing inode watches are FS_ACCESS and FS_EVENT_ON_CHILD > and those could be encoded in lower bits of connector pointer. Actually for children events, we have a dentry flag DCACHE_FSNOTIFY_PARENT_WATCHED and that should catch 99% of situation. FS_EVENT_ON_CHILD is used only to verify event really should be delivered since the DCACHE_FSNOTIFY_PARENT_WATCHED flag is cleared lazily. Or where do you think the performance of FS_EVENT_ON_CHILD checking matters? Also I'm not 100% sure just having FS_ACCESS checked quickly is going to buy us that much. We have quite a few event types and if someone is watching for a different event type than the current event (just not FS_ACCESS), we'll just have to pay the cost of srcu_read_lock and indirection. So it just depends whether we consider such loads worthwhile or not... Honza -- Jan Kara SUSE Labs, CR