On Mon, 1 May 2000, Stephen C. Tweedie wrote:
> Hi,
>
> On Fri, Apr 28, 2000 at 11:57:23AM -0700, Chris Mason wrote:
> >
> > The fs/inode.c and fs.h changes allow the FS to provide a dirty_inode
> > call. I'm using this to log the inodes instead of allowing them to hit
> > the dirty list, which saves me from deadlocks when try_to_free_pages
> > forces a flush of the dirty inode list.
>
> Isn't this going to be very inefficient when we are constantly
> updating the inode's atime for a series of file reads? I'd have
> thought that we'd _want_ to defer the writing of the inode as
> long as possible in that case, precisely to avoid logging the
> inode too many times.
>
Yes, there are a few cases this will be a speed hit. dbench, bonnie++ and
a few other tests didn't show it, I suspect it will be seen more on slower
CPUs.
The biggest reason this doesn't hurt as much as it should is that reiserfs
has to find the inode in the tree. Since this can involve reading blocks
off the disk, the delayed writing from mark_inode_dirty increases the
chance those buffers won't be in cache. This is why we suggest using
-o noatime mounts when for our 2.2 code (where we use generic_file_read).
Plus, logging a buffer frequently is usually less expensive than writing
it. I try to make a fast path for logging buffers that are already in the
current transaction. But, we still need to get the big kernel lock, and
the journal lock to join the transaction in my dirty_inode call. That's
much more overhead than mark_inode_dirty().
In other words, I'm not thrilled with this either ;-) Perhaps we could
get around the deadlock by allowing only one person to call prune_icache
at once, so that callers of try_to_free_pages will skip the inode flush if
another proc is already doing it.
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:08 EST