Rashmi Balasubramanyam wrote:
Thank you for the reply Sir. In the idea that you are suggesting wont there be
a lot of context switches between kernel and user lands?
Yes, but for large enough writes/buffer sizes (say 64k at a time), it
shouldn't matter.
For many small writes, it starts to make a difference. But perhaps you
can coalesce them somehow. One possible approach:
* when your driver does write(), use a strategy routine to attempt
to collect writes together... don't flush to your daemon until one of
the following conditions is true:
a) at least N bytes (e.g. 64K, 256K, or maybe 1M) are available for
writing
b) a timer expires -- maybe 10 msec is sufficient?
c) the file is closed
d) a non-sequential write arrives (but, tapes aren't seekable, are
they?)
With such an approach you could probably eliminate most of the syscall
overhead.
You could also use mmap() to map the files being written too, perhaps.
You could *certainly* use mmap() to use a shared region between the
userland daemon and your driver. (Which might help with some of the
copying of data, although you still need to take a context switch on
arrival of the data.)
--Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
