On Wed, Jun 6, 2012 at 6:33 AM, John Reitan john.reitan@arm.com wrote:

...

But maybe instead of inventing something new, we can just use 'struct kthread_work' instead of 'struct kds_callback' plus the two 'void *'s?  If the user needs some extra args they can embed 'struct kthread_work' in their own struct and use container_of() magic in the cb.

Plus this is a natural fit if you want to dispatch callbacks instead on a kthread_worker, which seems like it would simplify a few things when it comes to deadlock avoidance.. ie., not resource deadlock avoidance, but dispatching callbacks when some lock is held.

That sounds like a better approach. Will make a cleaner API, will look into it.

When Tom visited us for android graphics camp in the fall he argued that there were cases where we would want to avoid an extra schedule. Consider the case where the GPU is waiting for a render buffer that the display controller is using. If that render can be kicked off w/o acquiring locks, the display's vsync IRQ handler can call release, which in turn calls the GPU callback, which in turn kicks off the render very quickly w/o having to leave IRQ context.

One way around the locking issue with callbacks/async wait is to have async wait return a value to indicate that the resource has been acquired instead of calling the callback. This is the approach I chose in our sync framework.

-Erik