[lkml]   [2009]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 15/19] workqueue: reimplement workqueue flushing using color coded works
Hello, Linus.

Linus Torvalds wrote:
> On Thu, 1 Oct 2009, Tejun Heo wrote:
>> Reimplement workqueue flushing using color coded works. There are two
>> colors and each cwq has the current color which is painted on the
>> works being issued via the cwq. Flushing a workqueue is achieved by
>> flipping the current colors of each cwq and wait for the works which
>> have the old color to drain.
> Is there any reason for the "two colors" choice? I could imagine that it
> could end up being a limitation (and possible deadlock?) to allow just a
> single flush pending at any time.
> Could the color be an 8-bit counter or something like that instead?

It's related to how many bits can be used from work_struct->data which
in turn is determined by the alignment of cwq. Currently, the
alignment is 8 bytes so 3 bits are available. One is used for
PENDING, the other for LINKED and one last bit is used for COLOR.
Aligning cwq to, say, 64bytes wouldn't be bad at all and then we can
have 6-bits of coloring. Hmmm... yeap, I'll work on that.



 \ /
  Last update: 2009-10-01 19:15    [W:0.112 / U:24.380 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site