use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE
Signed-off-by: Nishanth Aravamudan <[email protected]>
Signed-off-by: Domen Puncer <[email protected]>
---
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);
_
[email protected] wrote:
>
> use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE
>
> Signed-off-by: Nishanth Aravamudan <[email protected]>
> Signed-off-by: Domen Puncer <[email protected]>
> ---
>
>
> 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))).
On Sun, 6 Mar 2005 19:44:14 -0800, Andrew Morton <[email protected]> wrote:
> [email protected] wrote:
> >
> > use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE
> >
> > Signed-off-by: Nishanth Aravamudan <[email protected]>
> > Signed-off-by: Domen Puncer <[email protected]>
> > ---
> >
> >
> > 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
Nish Aravamudan <[email protected]> wrote:
>
> > 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?
Let's forget about this one while we work out whether that code is doing
what we want it to do.