[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Dazuko-devel] 2.3.6-pre1 posted
From: |
Frantisek Hrbata |
Subject: |
Re: [Dazuko-devel] 2.3.6-pre1 posted |
Date: |
Tue, 22 Jul 2008 09:30:14 -0500 |
On Tue, 22 Jul 2008 09:53:16 +0300
"Tikka, Sami" <address@hidden> wrote:
> The reason I asked about the flags used in memory allocation was we had a
> problem on a customer machine where xp_malloc was returning NULL in the reply
> message buffer allocation. We also tried GFP_KERNEL and kernel complained
> about holding locks while calling kmalloc. Eventually we fixed it with:
>
> --- orig/dazuko_core.c
> +++ mod/dazuko_core.c
> @@ -3231,7 +3231,7 @@
> if (request->reply_buffer_size > 0)
> {
> /* allocate reply text buffer */
> - request->reply_buffer = (char
> *)call_xp_malloc(request->reply_buffer_size + 1);
> + request->reply_buffer = (char
> *)call_xp_bigmalloc(request->reply_buffer_size + 1);
> if (request->reply_buffer == NULL)
> {
> error = XP_ERROR_FAULT;
> @@ -3313,7 +3313,7 @@
> call_xp_free(request->buffer);
>
> if (request->reply_buffer != NULL)
> - call_xp_free(request->reply_buffer);
> + call_xp_bigfree(request->reply_buffer);
>
> call_xp_free(request);
> }
>
> Where xp_bigmalloc was defined with
>
> inline void *xp_bigmalloc(size_t size)
> {
> return vmalloc(size);
> }
>
> We used xp_bigmalloc because we had it in our dazuko for other purposes.
> Namely, we have implemented a scan result cache in dazuko. We haven't yet
> contributed it but will soon.
Hi,
generally it is a bad idea to use GFP_ATOMIC for all allocations like dazuko
did.
GFP_ATOMIC should be used only when it is really necessary, like in the irq
where you can not block. With GFP_ATOMIC kernel has limited possibilities how
to get
memory(pages) for your allocation. So there is much bigger possibility that the
allocation fails.
-FH