> Our system is a lot more complex than just 1 image source and 1 image=20
sink.
> We have several other processes that may also require images. The file,
> although it may have its drawbacks, does allow multiple processes to use =

the
> same image data without replicating it all over the place.

What Jochen is referring to -is somehow avoid using a file, so that it=20
never gets cached by the OS because you don't intend to write it to disk=20
anyway.
Even if you do use shared memory, pages can still get cached and some=20
Unix'es provide an option to make the region (or part of it) resident -in=20
which case the cache probably won't get into the picture.=20
On AIX, SHM=5FPIN is an advisory flag meaning it may not be honoured by the=
=20
VM. Im not sure how it works on NetBSD. So, do investigate before changing =

the whole design.

regards
-kamal

----- Original Message -----
From: "Jochen Kunz" <jkunz@unixag-kl.fh-kl.de>
To: "Daniel Brewer" <danielb@cat.co.za>
Cc: <tech-kern@netbsd.org>
Sent: Tuesday, July 08, 2003 10:16 AM
Subject: Re: fsync performance hit on 1.6.1


On 2003.07.07 09:45 Daniel Brewer wrote:

> For our application, we have 1 process capturing images from a
> frame-grabber and dumping them to a file in a memory file system.
> It sends a UDP message to another process that reads the images
> from this file and writes them to disk in a database.
Why don't you use a AF=5FUNIX socket to pipe the image data from process
to process or SYSV sharerd memory with semaphore interlocking? The later
would be the fastetst way to transfer the data and it avoids any file
system interaction.
--


tsch=FC=DF,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/