workqueue flush_work() patches

[Max Krasnyansky <maxk@qualcomm.com>]

Peter,
Oleg,

I'm not sure if you guys saw my last email on this. So I'll restart the 
thread.
If you guys are ok with the summary I provided below I can put all 
Oleg's patches into some git tree, test them on my boxes and resend to 
Andrew. I was also going to go over the users of flush_queued_work() and 
convert them to cancel_work_sync() and/or flush_work(). So I need to 
know if we want to go ahead with the flush_work() patches.
Please see summary below and let me know what you guys think.

Thanx
Max

----

Peter Zijlstra wrote:
 > Anyway, I think before we go further down this road, we'd better see
 > if anybody actually needs this. Not that theorizing about this problem
 > isn't fun,... but... :-)

Let me see if I can sum up current state of affairs. Looks like people 
are in general ok with Oleg's patches. Fancier stuff is much more 
complex and may not be needed.
Combining Oleg's patches with auditing current flush_scheduled_work() 
users and fixing them to use cancel_work_sync() (and in some cases 
flush_work()) gives us desired behaviour. Which is:
	1. minimizing flush overhead
	2. handling (actually avoiding) work queue thread starvation

Does that sound right ? Or did I miss something in the discussion ?

If that sounds right we should resend the patches to Andrew with formal 
ACKs because I do not seem them in mainline, linux-next or -mm.

Thanks
Max