I'm working with a device which is pretty basic, interaction with it is limited to it's memory mapped registers. At the moment I'm controlling the device by mapping it's memory region into user space.
Is there any performance limitation in terms of doing this instead of creating a device driver module and running it in the kernel, accessing it using read() and write() ?
I suppose that each user space access introduces some overhead. Do you use a kind of block move command ? I suppose this would be counted as a single access. If you need fast reaction to some hardware event, this can only be done by hardware interrupts and same need a kernel mode device driver.
-Michael
There can be a performance penalty. If you read or write contiguous blocks of data to/from the device, a device driver will perform better.
I am a favorite of user space solutions because:
- adding kernel space code can make the kernel instable
- kernel space is harder to debug
The questions to be asked here are
- how many system calls do you need to make per second?
- How fast is the your processor?
Each system call has an (almost) fixed overhead per system call. For example on a MPC862 processor (66mhz Powerpc risc processor with
16Kbyte cache) the overhead is less then 10 microseconds per system call (700 assembler instructions). On a MPC852t (66mhz Powerpc with 4Kbyte cache) it is about 50microSeconds. On a fast pentium it is less then a microsecond. So if you need to do thousands of system calls per second, considder writing a device driver. If you don't, it's easier to do everything in userspace.Paul Geerinckx
Thanks for the reply Michael.
I wasn't too sure about this, since it depends on whether or not each access to the memory area would result in a page fault. The device that I am working with requires only a few bytes of mapped memory, ie much less than the size of a page. Of course, it depends if other threads are running at the same time inside that process which cause more page faults each time there's a context switch.
Yes I definitely know that.
I have a driver at the moment which handles interrupts transparently and tells the user space application about them, but the user space app still goes in through a mapped region to deal with the cause of the interrupt (it's more like smart polling than true interrupt handling). I'm debating the merits of moving the device accesses into the kernel also, or whether they are more efficient where they are.
I agree with you on those counts, they are very good reasons to keep it all in user space.
The device I'm working with is a MIPS CPU running at 200Mhz with an 8k cache. I suspect the overhead for system calls would be in a similar order to the Pentium example you described above.
Thanks very much for your help.
Paul
If you have a driver anyway it would be easy to handle the data access there. The driver is accessed by the user software like a file. I don't know if this will improve the performance, as when accessing the driver a mode switch is necessary, anyways. The benefit is that you can access the hardware data a lot faster after the interrupt.
-Michael
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.