lkml.org 
[lkml]   [2008]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH -v3 0/8] file notification: fsnotify a unified file notification backend
From
Date
On Tue, 2008-11-25 at 16:14 -0800, Andrew Morton wrote:
> On Tue, 25 Nov 2008 12:20:51 -0500
> Eric Paris <eparis@redhat.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!



\
 
 \ /
  Last update: 2008-11-26 03:05    [W:0.205 / U:0.524 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site