[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090215141931.32d512ce@infradead.org>
Date: Sun, 15 Feb 2009 14:19:31 -0800
From: Arjan van de Ven <arjan@...radead.org>
To: Arjan van de Ven <arjan@...radead.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH 1/7] async: Asynchronous function calls to speed up
kernel boot
On Sun, 15 Feb 2009 11:16:36 -0800
Arjan van de Ven <arjan@...radead.org> wrote:
> On Fri, 13 Feb 2009 23:29:26 -0800
> Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> > On Fri, 13 Feb 2009 20:59:49 -0800 Arjan van de Ven
> > <arjan@...radead.org> wrote:
> >
> > > On Fri, 13 Feb 2009 16:22:00 -0800
> > > Andrew Morton <akpm@...ux-foundation.org> wrote:
> > >
> > > > It means that sometimes, very rarely, the callback function will
> > > > be called within the caller's context.
> > >
> > > for the cases that use it right now it is ok.
> >
> > That doesn't mean it's any good! There are only two callsites.
>
> .. in mainline.
> There's a few more in various maintainer trees.
>
> >
> > Plus there's the issue which I mentioned: if someone _does_ call
> > this from atomic context they'll only find out about their bug when
> > the GFP_ATOMIC allocation fails. This is bad!
>
> as far as I know all current and pending callsites can deal with
> GFP_KERNEL, so I would just switch it to that for those; solves the
> entire issue. (I do need to check the suspend/resume speed
> improvements, S/R tends to be tricky with interrupts-off)
>
btw if you have a poster child in the kernel that you would like to see
use the new stuff let me know; very often having one or two good use
cases makes the discussion and design a ton easier.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists