[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AC4E2D1.6030804@kernel.org>
Date: Fri, 02 Oct 2009 02:11:45 +0900
From: Tejun Heo <tj@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: jeff@...zik.org, Ingo Molnar <mingo@...e.hu>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Jens Axboe <jens.axboe@...cle.com>, rusty@...tcorp.com.au,
cl@...ux-foundation.org, dhowells@...hat.com, arjan@...ux.intel.com
Subject: Re: [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.
Thanks.
--
tejun
--
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