[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zdzav4yCFI0kAx7o@slm.duckdns.org>
Date: Mon, 26 Feb 2024 08:38:55 -1000
From: Tejun Heo <tj@...nel.org>
To: Allen <allen.lkml@...il.com>
Cc: jiangshanlai@...il.com, torvalds@...ux-foundation.org,
linux-kernel@...r.kernel.org, kernel-team@...a.com
Subject: Re: [PATCHSET wq/for-6.9,6.10] workqueue: Implement
disable/enable_work()
Hello,
Sorry about the late reply.
On Thu, Feb 22, 2024 at 12:26:35PM -0800, Allen wrote:
> I do understand the work bits, but I don't fully understand the
> concept of colors
> (work_color, flush_color). A swift overview of it would be highly appreciated.
That's just to group work items for flush_workqueue(). Let's say there are
work items which are queued in sequence, 1 to 8. Let's also say that there
are three flush_workqueue() attempts which take place after work item 2, 4
and 6. Then, the flush colors A, B, C, D are assigned so that:
work items 1 2 3 4 5 6 7 8
flush_workqueue ^ ^ ^
\-----/ \-----/ \-----/ \------~~~
flush_color A B C D
and the flush_workqueue() code waits for its preceding colors to be drained
to implement flushing.
It's just a way to keep track of the number of work items in flight which
were issued before a certain point in time. It's expensive to do that for
arbitrary number of points in time, so it just has N slots for groups and
calls them flush colors.
This shouldn't really matter for the bh conversion given that everyone
operates on individual work item.
Thanks.
--
tejun
Powered by blists - more mailing lists