Re: [PATCH 1/7] async: Asynchronous function calls to speed up kernel boot

[Cornelia Huck <cornelia.huck@de.ibm.com>]

On Sun, 15 Feb 2009 11:16:36 -0800,
Arjan van de Ven <arjan@infradead.org> wrote:

> * The caller needs to provide the memory
>    - solves the case of the internal implementation getting a failed
>      allocation. BUT it does not solve the caller not getting memory,
>      it shifts the complexity to there.
>    - ... or needs to cope with the call potentially failing if it
>      lets the infrastructure to do the allocation

We could provide a small wrapper that allocates memory for the simple
case - but having the caller provide the memory makes it more flexible.

> * The caller needs to wait (at some point) for the operation to
>   complete, and then take care of freeing the memory.
>   (the memory obviously could be part of some natural structure that
>    already has its own lifecycle rules)

So it's not so much freeing as giving up a reference.

> * There must be enough worker threads such that deadlocks due to all
>   threads waiting on each other will not happen. Practically this
>   probably means that if there is no progress, we need to just swallow
>   the pill and make more threads. In addition we can borrow the thread
>   context of the threads that are waiting for work to complete
>   - alternative is to have 2 (or more) classes of work with a reserved
>     thread pool for each, but I'm very not fond of this idea, because
>     then all the advantages of sharing the implementation go away again,
>     and over time we'll end up with many such classes
> * The caller is not allowed to use the same memory for scheduling
>   multiple outstanding function calls (this is fundamentally different
>   from schedule_work, which does allow this).
>   - we could make a flag that marks an item as "if the function and data
>     are the same silently allow it" but I'm not too fond of that idea,
>     it'll be fragile.

Agreed, that would be fragile. The caller should be able to take care
of it best.

> Practically: the scheduled function is not allowed to make the metadata
> memory go away. At least for those cases where we later want to wait
> for the opertation; in principle we could do away with this requirement
> if we know nobody will ever wait for the operation.

But that would artificially limit the usefulness.

> Second practical issue:
> We can have a flag in the metadata that says that the infrastructure is 
> supposed to kfree() the metadata at the end.

I tried that, but didn't like the result.

> Or we can go wild and stick
> a pointer in of the function that needs to be called to free the
> metadata.

krefs start to look attractive...