data transfer from kernel to user space
Hi , Normally we use copy_to_user / copy_from_user api's to transfer data to/from user space from/to kernel space . Can i be suggested with any other data transfer mechanism b/w kernel - user space for a char device , which are much faster than copy_xxx ? Regards Amit Nagal
Use a shared memory between user space and kernel space. The same physical memory can be translated as user-space virtual address as well as kernel space. See more about mmap, io_remap_pfn_range etc. and you will get an idea. The main advantage with this u can avoid copying data between two spaces but disadvantage associated is u need to request a fixed memory chunk from kernel for this purpose. On Tue, Jul 12, 2011 at 10:09 AM, Amit Nagal <helloin.amit@gmail.com> wrote:
Hi ,
Normally we use copy_to_user / copy_from_user api's to transfer data to/from user space from/to kernel space . Can i be suggested with any other data transfer mechanism b/w kernel - user space for a char device , which are much faster than copy_xxx ? Regards Amit Nagal
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, Jul 12, 2011 at 11:51 AM, Tirtha Ghosh <gtirtha@gmail.com> wrote:
Use a shared memory between user space and kernel space. The same physical memory can be translated as user-space virtual address as well as kernel space. See more about mmap, io_remap_pfn_range etc. and you will get an idea. The main advantage with this u can avoid copying data between two spaces but disadvantage associated is u need to request a fixed memory chunk from kernel for this purpose.
Thanx for reply . Regarding mmap usage , As per LDD3 , page 423 : "Not every device lends itself to the mmap abstraction; it makes no sense, for instance, for serial ports and other stream-oriented devices." . why mmap is not useful for stream-oriented devices ? After all even for stream-oriented device (as in my case ) , we need to copy data from kernel buffer to user-space buffer , and if copy can be avoided via any mechanism , it will be much faster . Regards Amit Nagal
On Tue, Jul 12, 2011 at 9:56 AM, Amit Nagal <helloin.amit@gmail.com> wrote:
On Tue, Jul 12, 2011 at 11:51 AM, Tirtha Ghosh <gtirtha@gmail.com> wrote:
Use a shared memory between user space and kernel space. The same physical memory can be translated as user-space virtual address as well as kernel space. See more about mmap, io_remap_pfn_range etc. and you will get an idea. The main advantage with this u can avoid copying data between two spaces but disadvantage associated is u need to request a fixed memory chunk from kernel for this purpose.
Thanx for reply . Regarding mmap usage , As per LDD3 , page 423 : "Not every device lends itself to the mmap abstraction; it makes no sense, for instance, for serial ports and other stream-oriented devices." .
why mmap is not useful for stream-oriented devices ? After all even for stream-oriented device (as in my case ) , we need to copy data from kernel buffer to user-space buffer , and if copy can be avoided via any mechanism , it will be much faster .
Usually, character oriented devices, are only aware of 'next byte' to send/receive. Think what would happen, if you map a memory area of 4K, but only 1 byte has arrived? You would need to find a way to tell user, that mmapped area is not yet ready to be read, or only the first byte is valid. Also, think if lseek makes sense on a serial device. thanks, Daniel.
On Tue, Jul 12, 2011 at 12:26:35PM +0530, Amit Nagal wrote:
After all even for stream-oriented device (as in my case ) , we need to copy data from kernel buffer to user-space buffer , and if copy can be avoided via any mechanism , it will be much faster .
Have you really measured your data rates and determined that the copy is slowing you down a lot? If so, how much? And how would you get data that you are copying from a streaming device (what type is it), into userspace without doing a copy? DMA is the only way that it can be done, would that work for you? What driver are you using? What type of device? And again, have you measured things to really determine that this is the slow point? Usually it's the data speed coming in to the device itself that is the slowest part, and you can't do anything about that in the kernel. greg k-h
participants (4)
-
Amit Nagal -
Daniel Baluta -
Greg KH -
Tirtha Ghosh