Subject: Re: fsync performance hit on 1.6.1
To: None <tech-kern@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-kern
Date: 07/08/2003 14:06:22
>> Our system is a lot more complex than just 1 image source and 1
>> image sink. We have several other processes that may also require
>> images.
> You can share memory with several processes. E.g. one writes and 10
> other processes are reading it.
Yes indeed, and it can greatly improve performance. (I've often wished
for a way to send mappings for memory through AF_LOCAL sockets, so that
unrelated processes can rendezvous with an AF_LOCAL socket and share
memory without needing to have a file around to be mmap()ped.
Alternatively, a way to get a file descriptor on a memory area; that
descriptor could then be passed by existing mechanisms and mmap()ped to
produce the sharing.)
I once wanted to build something like dd but that overlapped reads and
writes. I ended up making it mmap MAP_ANON memory before forking into
a reader process and a writer process; they transferred ownership of
large blocks of memory by sending tiny tokens through a pipe. It
greatly improved speed when doing large copies from one raw disk to
another, even if they're on the same SCSI bus.
If your processes have a common ancestor that can map memory for them,
you could do likewise. If not, you may have to create a file for them
to mmap(), ugly as it may be.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B