Messages in this thread |  | | | Date | Wed, 13 May 2009 11:27:10 +0800 | | Subject | Re: [PATCH] kernel/async.c:introduce async_schedule*_atomic | | From | Ming Lei <> |
| |
2009/5/13 Cornelia Huck <cornelia.huck@de.ibm.com>: > On Tue, 12 May 2009 18:52:29 +0200, > Frederic Weisbecker <fweisbec@gmail.com> wrote: > >> This division would make more sense indeed. >> >> - async_schedule_inatomic() would be nosync() and would use >> GFP_ATOMIC. I guess the case where we want to run >> a job synchronously from atomic in case of async failure is too rare >> (non-existent?). > > It would add complexity for those callers providing a function that is > safe to be called in both contexts.
So we introduce async_schedule*_inatomic(), the patch aims at making caller clear that async_schedule*_inatomic() should be used in atomic contexts instead of async_schedule*().
> >> - async_schedule_nosync() would be only nosync() and would use >> GFP_KERNEL
I wonder if there is such kind of requirement, can we not introduce it in the patch? If someone does need it, we can introduce it later.
>> >> I'm not sure the second case will ever be used though. > > It might make sense for the "just fail if we cannot get memory" case. > >> >> Another alternative would be to define a single async_schedule_nosync() >> which also takes a gfp flag. > > Wouldn't async_schedule() then need a gfp flag as well? >
IMHO, it is better that async_schedule() is always called in non-atomic contexts and async_schedule*_inatomic() is always called in atomic contexts, so we can't need a gfp flag, right?
-- Lei Ming -- 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/
|  |