Messages in this thread | | | Date | Sun, 6 Mar 2005 21:01:11 -0800 | From | Nish Aravamudan <> | Subject | Re: [patch 12/14] drivers/dmapool: use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE |
| |
On Sun, 6 Mar 2005 19:44:14 -0800, Andrew Morton <akpm@osdl.org> wrote: > 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?
Sorry, far beyond my abilities :(
> 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?
Yup, didn't make much sense to me.
> 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))).
Ok, I will re-spin this patch. Or would you prefer an incremental one?
Thanks, Nish - 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/
| |