Re: [PATCH] kernel:async function call:introduce async_run

[Ming Lei <tom.leiming@gmail.com>]

2009/5/13 Cornelia Huck <cornelia.huck@de.ibm.com>:
> On Wed, 13 May 2009 20:56:40 +0800,
> Ming Lei <tom.leiming@gmail.com> wrote:
>
>> 2009/5/13 Cornelia Huck <cornelia.huck@de.ibm.com>:
>> > On Wed, 13 May 2009 08:33:49 +0800,
>> > tom.leiming@gmail.com wrote:
>
>> >>  /**
>> >> + * async_run - schedule a function for asynchronous execution
>> >> + * @ptr: function to execute asynchronously
>> >> + * @data: data pointer to pass to the function
>> >> + *
>> >> + * Note:we do not allocate a cookie for this kind of aysnchronous
>> >> + * function to decrease the wait time of async_synchronize_full().
>> >
>> > But async_synchronize_full() still waits for list_empty(&async_running)
>> > - so what does this buy us?
>>
>> I mean it can decrease the wait time for other async function.
>> async_schedule() still can be used to do such thing, but may lead to a
>> slower boot.  It is the main
>> purpose of the patch.
>
> I see how this can affect places calling async_synchronize_cookie(),
> but the function will still end up on async_running. If you don't want
> async_synchronize_full() waiting for these functions, couldn't you use
> your own running list?
>
> (Oh, and I just thought about it a bit further:
> - somebody calls async_run() -> function with cookie = MAX_COOKIE will be
>  lowest_in_progress at some point in time
> - somebody else calls async_schedule() -> cookie = n
> - we wait with async_synchronize_cookie(n) - which returns since
>  MAX_COOKIE >= n, which is probably not what we want)
>
yes , you are right, I'll think about it.



-- 
Lei Ming