[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1227664851.3320.10.camel@localhost.localdomain>
Date: Tue, 25 Nov 2008 21:00:51 -0500
From: Eric Paris <eparis@...hat.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
viro@...iv.linux.org.uk, alan@...rguk.ukuu.org.uk,
arjan@...radead.org, hch@...radead.org, a.p.zijlstra@...llo.nl
Subject: Re: [PATCH -v3 0/8] file notification: fsnotify a unified file
notification backend
On Tue, 2008-11-25 at 16:14 -0800, Andrew Morton wrote:
> On Tue, 25 Nov 2008 12:20:51 -0500
> Eric Paris <eparis@...hat.com> wrote:
>
> > This series only reimplements dnotify using the new fsnotify backend. If
> > accepted I will do the work to port inotify as well. Currently struct inode
> > goes from:
> >
> > #ifdef CONFIG_DNOTIFY
> > unsigned long i_dnotify_mask; /* Directory notify events */
> > struct dnotify_struct *i_dnotify; /* for directory notifications */
> > #endif
> >
> > to:
> > #ifdef CONFIG_FSNOTIFY
> > unsigned long i_fsnotify_mask; /* all events this inode cares about */
> > struct list_head i_fsnotify_mark_entries; /* fsnotify mark entries */
> > spinlock_t i_fsnotify_lock; /* protect the entries list */
> > #endif
> >
> > so the inode still grows, but the inotify fields will be dropped as well
> > resulting in a smaller struct inode. These are all the fields fanotify will
> > want as well.
>
> Did you consider using i_lock to protect that list? Its mandate is "an
> innermost lock which protects fields within the inode".
I didn't really consider it. It absolutely could be used. Currently
dnotify used the i_lock and inotify uses it's own smaller mutex. If
people like I can try to run some perf tests between using i_lock and
this smaller lock and would gladly send a patch on top of this set to
drop the i_fsnotify_lock.
> > 29 files changed, 3100 insertions(+), 1977 deletions(-)
>
> if (code > code_reviewers)
> fix();
>
> but how?
patch #1 does nothing but move dnotify and inotify...
14 files changed, 1929 insertions(+), 1925 deletions(-)
So that total number seems worse than it is (but I'll agree that all of
this for no new functionality sucks. But at least I promise a smaller
inode struct at the end!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists