I'm involved in a porting project which is showing big performance
problems under Linux, but not under a variety of other OSes, including
FreeBSD, Solaris, and IRIX. We seem to be spending a much longer time in
msync() under Linux than in those other operating systems.
Specifically, a data structure in memory is periodically synced with
the disk, using msync(..., MS_SYNC). The memory buffer is not traversed
linearly, but rather the msync calls interleave between two or three
different buffers. We're getting about 8.25 milliseconds in each of 192
such msync() calls, and our multi-threaded program becomes much less
responsive for a bit over a second while it services this.
Now, this is not supposed to take that long, because dirty pages are
expected to be very sparse in this data structure over the time interval
between updates. We expect that if msync() asks for a certain 16kB block
to be synced to disk, that only those pages which are dirty will result
in a head seek and bit scribbling, and if the buffer is clean then the
syscall will return essentially immediately, but that does not seem to be
the case.
The kernel we're using is 2.2.12 SMP, from RedHat 6.1, with the memory
mapped file on an ext2 file system on a SCSI disk.
I've been wandering through sys_msync() in the kernel sources for a
while, but I'm hoping somebody with more intimate knowledge of the
subject can answer this off the top of their head and save me a bit of
time. Are all pages in an msync() always sent to disk? If not, then I
should look in the userland for something dirtying those pages in Linux
but not in the other OSes. If so, is there something I can do to avoid
the performance loss?
Thank you for any assistance.
-- Christopher Neufeld Christopher.Neufeld@dynacan.org Home page: http://caliban.physics.utoronto.ca/neufeld/ "Don't edit reality for the sake of simplicity"- 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 : Mon May 15 2000 - 21:00:16 EST