[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <486525FE.1060509@qualcomm.com>
Date: Fri, 27 Jun 2008 10:40:14 -0700
From: Max Krasnyansky <maxk@...lcomm.com>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>, oleg@...sign.ru,
jarkao2@...pl
CC: linux-kernel@...r.kernel.org
Subject: workqueue flush_work() patches
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists