lkml.org 
[lkml]   [2005]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 12/14] drivers/dmapool: use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE
domen@coderock.org wrote:
>
> use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE
>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> Signed-off-by: Domen Puncer <domen@coderock.org>
> ---
>
>
> kj-domen/drivers/base/dmapool.c | 2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> diff -puN drivers/base/dmapool.c~task_unint-drivers_base_dmapool drivers/base/dmapool.c
> --- kj/drivers/base/dmapool.c~task_unint-drivers_base_dmapool 2005-03-05 16:11:21.000000000 +0100
> +++ kj-domen/drivers/base/dmapool.c 2005-03-05 16:11:21.000000000 +0100
> @@ -293,7 +293,7 @@ restart:
> if (mem_flags & __GFP_WAIT) {
> DECLARE_WAITQUEUE (wait, current);
>
> - current->state = TASK_INTERRUPTIBLE;
> + set_current_state(TASK_UNINTERRUPTIBLE);
> add_wait_queue (&pool->waitq, &wait);
> spin_unlock_irqrestore (&pool->lock, flags);

This code is alread a bit odd. If we're prepared to sleep in there, then
why use GFP_ATOMIC?

If it is so that we can dig a bit deeper into the free page pools then
something like __GFP_WAIT|__GFP_HIGH would be preferable.

And why isn't mem_flags passed into pool_alloc_page() verbatim?

I agree on the TASK_UNINTERRUPTIBLE change: if the calling task happens to
have signal_pending() then the schedule_timeout() will fall right through.
Why should we change kernel memory allocation strategy if the user hit ^C?

Also, __set_current_state() can be user here: the add_wait_queue() contains
the necessary barriers. (Grubby, but we do that in quite a few places with
this particular code sequence (we should have an add_wait_queue() variant
which does the add_wait_queue+__set_current_state all in one hit (but let's
not, else I'll be buried in another 1000 cleanuplets))).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:10    [W:0.039 / U:0.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site