Messages in this thread | | | Date | Wed, 13 May 2009 09:47:28 +0200 | From | Cornelia Huck <> | Subject | Re: [PATCH] kernel/async.c:introduce async_schedule*_atomic |
| |
On Wed, 13 May 2009 03:20:13 +0200, Frederic Weisbecker <fweisbec@gmail.com> 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.
| |