The images are compressed, and each ranges from about 10KB to 30KB in size.
fdPostBuf is a handle to a file that is never more than 18MB in size - once
the end is reached, just start from the beginning again.

----- Original Message -----
From: "Manuel Bouyer" <bouyer@antioche.eu.org>
To: "Daniel Brewer" <danielb@cat.co.za>
Cc: <tech-kern@netbsd.org>
Sent: Wednesday, July 02, 2003 9:43 PM
Subject: Re: fsync performance hit on 1.6.1


> On Wed, Jul 02, 2003 at 02:18:15PM +0200, Daniel Brewer wrote:
> > Hi
> >
> > When comparing our software's CPU utilization running on 151 & on 161, I
noticed an inexplicably high usage on 161. After digging deeper with gprof,
I found that an fsync on 161 takes significantly longer than on 151. Our
software writes captured images into a ring buffer in a memory file-system,
so other servers can retrieve them. Could someone explain the why fsync on
1.6.1 is so significantly slower than on 1.5.1? Is there a work-around? Or
perhaps a completely different way of doing this?
> >
> > The process involved after capture, is as follows:
> >
> > flock(fdPostBuf, LOCK_EX)
> > lseek(fdPostBuf, img_offset, SEEK_SET)
> > write(fdPostBuf, img_buf, img_size)
> > fsync(fdPostBuf)
> > flock(fdPostBuf, LOCK_UN)
>
> How large is img_size ?
> I suspect this is a side effect of the unified buffer cache: in 1.6.x the
> whole image is buffered, while with 1.5.x ony part of it is. As a
consequence,
> fsync() on 1.6 has much more work to do; on the other hand write() should
> complete immediatly, where it would block on buffer I/O in 1.5.x
>
> --
> Manuel Bouyer <bouyer@antioche.eu.org>
>      NetBSD: 24 ans d'experience feront toujours la difference
> --
>