Kernel tempory memory alloc

Kernel tempory memory alloc

[James Courtier-Dutton]

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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Kernel tempory memory alloc

[Fawad Lateef]

On 11/19/05, James Courtier-Dutton <James@superbug.demon.co.uk> wrote:
>
> 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!

> 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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Kernel tempory memory alloc

[Andi Kleen]

On Saturday 19 November 2005 19:57, Fawad Lateef wrote:
> On 11/19/05, James Courtier-Dutton <James@superbug.demon.co.uk> wrote:
> > 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!

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.

> > 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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>