Hello,
For a new driver I'm wondering what the overhead is on read and ioctl
systemcalls... Did anyone ever measure those and put the measurements on
the web somewhere? The driver I'm currently working on would need
between 40000 and 80000 systemcalls/sec, depending on the datastream
coming in (outgoing is non-existent). So if a syscall would be 2usec,
that would consume between 80ms and 160ms... this would take quite a big
cut of available processor power. (The 2us number is based on a
measurement I found on the web for gettimeofday() on a pentium 133,
using 2.0.27, which measured 2.7us for one gettimeofday call; however
I'll be using a PIII-500 with 2.2.14 (or 15) so it'll be lower)
So I've been thinking of alternatives...
Internally the driver uses a queue where the driver pushes data into and
a user application takes the data out (producer-consumer scenario).
However, due to the nature of the data (there are three types, for
example) and the fact that the user can return used databuffers in a
different order, it cannot be a regular circular databuffer but it'll
have to be a queue with structs which have pointers to the databuffers
and some descriptive information. The databuffers are mmaped.
What I'm considering is, instead of using (abusing) read or ioctl to get
entries from the queue to the user, is to expose the queue to the user
so it can directly manipulate the queue without using systemcalls.
Would this be possible? Obviously I'd need to put the user to sleep in
the case when the queue is empty, requiring a systemcall which is not a
problem in this situation. But in the case when the queue is not empty
I'd like to be able to extract items without using systemcalls, which is
(I think) also possible. What options would be available for locking
mechanisms?
Any comments would be highly appreciated!
Thanks,
Jan Evert
-
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 : Sun May 07 2000 - 21:00:14 EST