Thanks Steve.
On Wed, Feb 25, 2004 at 07:58:24AM -0600, Steve Lord wrote:
>
> Only speaking for 2.6 here, so take that under advisement.
After an audit, this seems to be valid for both 2.4 and 2.6.
> There are very few callers of fsync in the kernel, and they all do the
> data flush and wait for data themselves, the filesystem fsync code is
> not involved in the data flush at all for most filesystems, just the
> metadata for the file. The callers hold the i_sem, but not the nfs
> commit case.
Mmmm? seems to me that i_sem is also held for nfs commit, both
in 2.4 and 2.6 (nfsd_commit -> nfsd_sync -> down(i_sem) ->
nfsd_dosync -> fop->fsync).
> As for flushing data without the IO lock, I think this is OK in general,
> if a new read comes along there is no problem, if a new write modifies
> the page then it will get redirtied and flushed again later. If a
> truncate removes the page then it will delete the page before after
> it is flushed. The holding of the IO lock is partially a hold over
> from Irix where it is required around the VOP_FLUSH..... calls.
Yep, OK, thanks.
> The tosspages and flushinval pages cases do need the lock though.
>
> This is untested, but should generally speed things up in 2.6. A very
> quick scan of 2.4 seems to suggest a similar change will work there
> too.
I think its always valid to do this (after auditing the callers),
but doesn't seem to do "general speedup" - the "usual suspects"
benchmarks don't show any improvements anyway. Alex, what was
your workload? (you didn't get back to me yet).
cheers.
--
Nathan
|