Hello Stephen,
In linux-2.6.7/fs/dnotify.c, the local varible dn_lock is
declared as rw_lock_t, but the lock is only taken exclusively.
So, let's "document" this fact, save a few bytes and save a few
cycles by changing it to spinlock_t.
I have tried running the dnotify user level program on
a multiprocessing kernel with this change, and it seems fine.
In the near future, I expect to try to eliminate dn_lock by
using parent_inode->i_sem instead, as the kmem_cache_t in dnotify.c
does not need to be protected by a separate lock. However, such a
change would require changes to the callers into dnotify, which
currently make conflicting assumptions about whether they should
be holding parent_inode->i_sem, child_inode->i_sem or neither when
they call dnotify_parent or inode_dnotify, so that will require
modifying many of the places that call into dnotify. So, I'd like
to integrate this minor change first.
If this patch looks acceptable to you, could you please
tell the appropriate person to integrate it or advise me what to
do if you want me to proceed some other way? I don't know if you
submit your patches directly to Linus or through someone else,
like Al Viro.
--
__ ______________
Adam J. Richter \ /
[email protected] | g g d r a s i l
"Adam J. Richter" <[email protected]> wrote:
>
> In the near future, I expect to try to eliminate dn_lock by
> using parent_inode->i_sem instead, as the kmem_cache_t in dnotify.c
> does not need to be protected by a separate lock.
inode->i_lock would be better. Take care to keep it an "innermost" VFS
lock though. Move kmem_cache_free() outside the lock altoghter.
On Thu, Jun 17, 2004 at 03:53:13AM -0700, Andrew Morton wrote:
> "Adam J. Richter" <[email protected]> wrote:
> >
> > In the near future, I expect to try to eliminate dn_lock by
> > using parent_inode->i_sem instead, as the kmem_cache_t in dnotify.c
> > does not need to be protected by a separate lock.
>
> inode->i_lock would be better. Take care to keep it an "innermost" VFS
> lock though.
Thank you for the suggestion. I was not aware of inode->i_lock.
Looking at other users of inode->i_lock, I believe that using
inode->i_lock should not cause any conflict. The lock for
inode->i_dnotify is only taken when someone calls the dnotify ioctl
or if there actually is a match to some dnotify event, so the change
in lock contention between a single dn_lock and inode->i_lock (which
is obviously used elsewhere) should be minimal. The text + data of
the .o file generate on x86 was actually 32 bytes smaller when I
switched to inode->i_lock, and, of course, it made the source code
1 line shorter.
>Move kmem_cache_free() outside the lock altoghter.
Per your suggestion, I've done that in fcntl_dirnotify().
This wipes out the trivial space saving from switching to
inode->i_lock, but it's probably more important to avoid holding
inode->i_lock unnecessarily anyhow. My removal of one of the
goto labels had no effect on object code size on my x86
configuration.
The other places that call kmem_cache_free() with the lock
held do so because they are iterating through inode->i_dnotify, and
may have to call kmem_cache_free() repeatedly.
Here is an updated patch.
--
__ ______________
Adam J. Richter \ /
[email protected] | g g d r a s i l
Hi Adam,
On Thu, 17 Jun 2004 16:38:26 -0700 "Adam J. Richter" <[email protected]> wrote:
>
> In linux-2.6.7/fs/dnotify.c, the local varible dn_lock is
> declared as rw_lock_t, but the lock is only taken exclusively.
> So, let's "document" this fact, save a few bytes and save a few
> cycles by changing it to spinlock_t.
Fine by me, but other opinions are always welcome.
> If this patch looks acceptable to you, could you please
> tell the appropriate person to integrate it or advise me what to
> do if you want me to proceed some other way? I don't know if you
> submit your patches directly to Linus or through someone else,
> like Al Viro.
Well, Al was the last to modify the dnotify code, if memory serves.
Getting his OK is always a good idea for this sort of thing. Otherwise,
fine my me.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/