Re: Freezeable workqueues [Was: 2.6.22-rc1: Broken suspend on SMP with tifm]

[Oleg Nesterov <oleg@tv-sign.ru>]

On 05/14, Rafael J. Wysocki wrote:
>
> On Monday, 14 May 2007 18:55, Oleg Nesterov wrote:
> > 
> > Rafael, I am afraid we are making too much noise, and this may confuse Alex
> > and Andrew.
> > 
> > First, we should decide how to fix the bug we have in 2.6.22. I prefer a simple
> > "make freezeable workqueues singlethread" I sent. It was acked by Alex, it is
> > simple, and it is also good because tifm doesn't need multithreaded wq anyway.
> 
> Yes, I've already agreed with that.

Ah, OK, I misunderstood your message as if you propose this fix for 2.6.22.

> > 	- Do we need freezeable workqueues ?
> 
> Well, we have at least one case in which they appear to be useful.

So, in the long term, should we change this only user, or we think we better fix
freezeable wqs again?

> > WORK2->func() completes.
> > 
> > freezer comes. cwq->thread notices TIF_FREEZE and goes to refrigerator before
> > executing that barrier.

This is not possible. cwq->thread _must_ notice the barrier before it goes to
refrigerator.

So, given that we have cpu_populated_map we can re-introduce take_over_work()
along with migrate_sequence and thus we can fix freezeable multithreaded wqs.

> > If we have take_over_work() we should use it for any workqueue,
> > freezeable or not. Otherwise this is just a mess, imho.

Still, this is imho true. So we'd better do some other changes to be consistent.

-------------------------------------------------------------------------------
> Yeah, I need to learn more.

No. I should read the patches more carefully before complain.

> Sorry for the confusion I made.

Rafael, it is me who have to apologize.
-------------------------------------------------------------------------------

Oleg.