Re: [PATCH] kernel/async.c:introduce async_schedule*_atomic

[Cornelia Huck]

On Wed, 13 May 2009 03:20:13 +0200,
Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote:

> On Wed, May 13, 2009 at 08:28:15AM +0800, Ming Lei wrote:

> > Also we still allow async_schedule*()  to run a job synchronously if
> > out of memory
> > or other failure. This can keep consistency with before.
> 
> 
> Yes, but also most of the current users of async_schedule() could call
> it with GFP_KERNEL. For now it's not an issue because it is not widely
> used, but who knows how that will evolve...

Well, if we want to change the interface, now would be a good time
since there are still few callers.

> 
> 
> > Any sugesstions or objections?
> 
> 
> I have shared feelings. I don't know if the dual sense of
> this new helper deserves enough disambiguation and granularity
> to be split up in two parts:
> 
> - adding an async_schedule_nosync() helper
> - add a new gfpflag_t parameter
> 
> 
> Or should we just do:
> 
> - adding async_schedule_inatomic() which is a merge of nosync + GFP_ATOMIC
> - use GFP_KERNEL in async_schedule()
> 
> 
> It depends on the future users. Will someone ever accept to schedule a job
> that could end up running synchronously in the worst case?

The current callers all look simple enough, it may be that all other
cases besides inatomic+nosync would be overkill (and a too complex api
may lead to confusion).

Do people have candidates for conversion to the async api in mind that
would need one of the complex atomic/sync or non-atomic/non-sync
versions? If no, maybe we should just use the second approach and make
sure that the semantics are well documented.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/