* Gregory Haskins [off-list ref] wrote:

quoted

as far as the prioritization of function calls goes, _that_ makes 
sense, but it should not be a separate API but should be done to our 
normal workqueue APIs. That not only extends the effects of 
priorities to all current workqueue using kernel subsystems, but 
also keeps the API more unified. We really dont want to have too 
many -rt specific APIs.

I agree with you that having some kind of priority and cpu-binding 
specifiers for work-queues would be very cool indeed.  However, note 
that I didn't actually introduce a new API(*), per se.  I simply 
worked under the existing smp_call_function[_single]() API.

Using the smp_call_functions is critical design factor, however.  I 
really want clients of this function to seamlessly transition to 
threaded mode. [...]

well, 'clients' of this function are low-level architectural bits like 
the scheduler and the TLB flush code which stays atomic nevertheless. 
smp_call_function() is _not_ a true generic framework and to 'thread' it 
is wrong and misplaced and leads to the kind of over-complification that 
your patch shows. Please work based on the workqueue APIs.

	Ingo