Kernel tempory memory alloc
Hi,
I am going to implement an IOCTL for a particular driver.
Previously I might have used the stack to store the request/response in while using copy_to/from_user, but with the 4K stack limit, I must consider other alternatives. The IOCTL will be a simple request/response type, so the memory allocation will be for a very short time. Which is the correct memory api to use when allocating short term temporary memory in the kernel. Alternatively, is there a way to handle this by simply moving a page from user space to kernel space and then back to user space again?
Thus reducing the amount of memcpy.
James
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 4 lines · James Courtier-Dutton
The IOCTL will be a simple request/response type, so the memory allocation will be for a very short time. Which is the correct memory api to use when allocating short term temporary memory in the kernel.
I mostly/vastly used and saw memory allocation API "kmalloc" for small memory allocations. And for short-term and fast memory allocation use GFP_ATOMIC flag with memory allocation functions!
Quoted 4 lines
Alternatively, is there a way to handle this by simply moving a page from user space to kernel space and then back to user space again? Thus reducing the amount of memcpy.
I think memcpy is not a big-overhead as compare to temporary mapping a page from user space to kernel space and then unmapping it each time an ioctl is called, so you might try to constantly share a buffer between user/kernel space through which you can access data directly from both spaces (for mapping user page in kernel you can see get_user_pages) !
--
Fawad Lateef
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 8 lines · Fawad Lateef
Quoted 3 lines · James Courtier-Dutton
The IOCTL will be a simple request/response type, so the memory allocation will be for a very short time. Which is the correct memory api to use when allocating short term temporary memory in the kernel.
I mostly/vastly used and saw memory allocation API "kmalloc" for small memory allocations. And for short-term and fast memory allocation use
GFP_ATOMICflag with memory allocation functions!
No, that's not what GFP_ATOMIC is good for. Please don't spread misinformation like that which google will keep forever. GFP_ATOMIC is for allocating for interrupt context or other contexts where you cannot sleep, and is much less reliable than normal GFP_KERNEL.
Quoted 10 lines
Quoted 3 lines
Alternatively, is there a way to handle this by simply moving a page from user space to kernel space and then back to user space again? Thus reducing the amount of memcpy.
I think memcpy is not a big-overhead as compare to temporary mapping a page from user space to kernel space and then unmapping it each time an ioctl is called, so you might try to constantly share a buffer between user/kernel space through which you can access data directly from both spaces (for mapping user page in kernel you can see
get_user_pages) !
I don't think that's good advice. It depends on the exact circumstances and the size of the data, but for reasonably sized data (> one page) normally the copy should be more expensive.
Also there is no memcpy from user space of course.
-Andi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>