Cost of driver API calls from user space

1
votes

This is all in Linux and C.

I have a user space library function that will need to call a device driver's read/write function up to 8 times. (I am writing the library and device driver.) I see two ways of achieving this:

  1. Have the library call read/write the needed number of times.
  2. Have the driver handle reading/writing to the device the needed number of times.

The driver would already know the needed number of times based on a previous ioctl call that will happen regardless. Option 1 requires more switching between user space and kernel space which I know reduces performance. On the other hand, option 2 creates issues. For a read call, the buffer passed back to user space would be up to 8 times larger unless it's possible to pass 1 read at a time back to user space without switching between the two modes. A write call would also have the same issue unless the same data is to be written each time. So worst case for option 2 requires a buffer 8 times larger being passed back and forth as opposed to option 1.

Ultimately, which one is more efficient?

1
clinuxlinux-kernellinux-device-driver
Benchmark it. Then worry .. or sleep soundly. I would go with the simple #1 unless it was shown that the overhead was sufficiently high -- don't forget to account for the time of the call itself, the over head of managing data with #2, and how [in]frequently this request is made. Relatively large overheads performed infrequently are generally "inconsequential". What might make sense in context of an OpenGL driver might not make sense elsewhere. – user166390
I don't know if this will help or not, but you may also want to consider using a scatter-gather API similar to the readv(2)/writev(2) system calls. It doesn't help reduce the total memory usage, but in some situations it can help reduce the number of times the data is copied in memory, which helps improve cache performance. – Adam Rosenfield
I agree with pst, but would add that changing the semantics of the read/write interface for performance reasons is not the best place to start. You might change the read/write calls into a specific ioctl() for the device? But in any case, implement the simple way, benchmark and see if it needs changing. – MikeK

1 Answers

0
votes

As the commentators suggested, if efficiency is your concern, there is no amount of speculation should be a substitute for benchmarking and profiling. "Efficiency" can be affected by a huge number of factors and profiling each of your options is the right way to identify the best one.