User space vs kernel space device access

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View

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() ?

--


Re: User space vs kernel space device access
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

Re: User space vs kernel space device access
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Re: User space vs kernel space device access
Quoted text here. Click to load it

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

Re: User space vs kernel space device access
Quoted text here. Click to load it
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

Re: User space vs kernel space device access

Quoted text here. Click to load it

I agree with you on those counts, they are very good reasons to keep it
all in user space.

Quoted text here. Click to load it

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.












Re: User space vs kernel space device access
Quoted text here. Click to load it
 > I have done some work on a broadcom MIPS CPU (200Mhz, i dont remember
the cache size), but it was about 5 microseconds. Notice in the examples
above that the instruction cache size is very inportant. The MPC862 and
the MPC852t run on the same boards, the same clock, same bus, identical
processor core, same SDRAM but the only difference that matters is the
instruction cache size. So an instruction cache size of 16Kbyte is
sufficient, 4 Kbytes slows down the machine tremendously. I have no
expierience with instruction cache size of 8 kbyte. Note: The slow
MPC852t has 4Kbyte instruction AND 4kbyte data cache. The MPC852 has 16K
  IC AND 8Kb DC.
Quoted text here. Click to load it
Paul

Site Timeline