Re: [PATCH 2/3] workqueue: Maintain pwq->total_in_flight

[Breno Leitao <leitao@debian.org>]

On Tue, Sep 01, 2026 at 11:09:28AM -1000, Tejun Heo wrote:
> pwq_busy() scans all of pwq->nr_in_flight[] to tell whether anything is in
> flight. Maintain the sum in pwq->total_in_flight, which fits in existing
> padding, and test that instead.
> 
> Signed-off-by: Tejun Heo <tj@kernel.org>

Reviewed-by: Breno Leitao <leitao@debian.org>

I've found that the color is either used as 'unsigned int', and
sometimes as 'int'.

The color is 'int' in get_work_color(), work_color_to_flags(),
work_next_color(), in the work_color/flush_color fields of
pool_workqueue, workqueue_struct and wq_flusher, and in the
flush_workqueue_prep_pwqs() parameters - but it is 'unsigned int' in
worker->current_color and in insert_wq_barrier()'s local, which is one
of the two callers you're converting.

It's not a big deal: the value wraps at WORK_NR_COLORS, so it is always
[0, 15] and everything round-trips. It does leave oddities like

        worker->current_color = INT_MAX;

storing INT_MAX into an unsigned int. I may send a patch later to make
them all the same type - it would have to be 'int', since -1 is a live
sentinel for flush_color and flush_workqueue_prep_pwqs() documents "<
0 for no-op".