Re: [PATCH v4] tools/workqueue/wq_dump.py: Add busy worker inspection and BH pool states

[Aaron Tomlin]

On Wed, Sep 30, 2026 at 07:35:17AM -1000, Tejun Heo wrote:
> Hello, Aaron.
> 
> On Wed, Sep 30, 2026 at 10:39:58AM -0400, Aaron Tomlin wrote:
> > +  flags     pool flags (bh, draining, disassociated)
> 
> bh-hi is missing. Also, the pool line already has a numeric flags=0x..
> field, so using the same label for these is a bit confusing.

Acknowledged. In the next iteration, I have documented "flags" as the hex
pool flags field and renamed the trailing state indicators entry to
"state", including "bh-hi":

    flags     pool flags in hex
    ...
    state     pool state (bh, bh-hi, draining, disassociated)

> 
> > +            bh_type = 'bh-hi' if pool.attrs.nice == HIGHPRI_NICE_LEVEL else 'bh'
> 
> The busy worker loop computes this again. Maybe compute it once per pool
> and reuse it there?

Agreed. I have initialised bh_type = None once per pool, set it when
POOL_BH is present, and reused it directly inside the busy worker loop.

> 
> > +        for bkt in pool.busy_hash:
> > +            if incomplete:
> > +                break
> 
> After the first bad bucket, this and the break in the except below skip
> the rest of the pool. Maybe move on to the next bucket instead? The
> warning still gets printed and the busy workers in the other buckets
> aren't lost.

That makes much more sense since each bucket's hlist chain is independent.
I have dropped the early break at the top of the bucket loop and the break
in the except block so that iteration continues across the remaining
buckets while still setting incomplete = True.

> 
> > +                            elif worker.task.value_():
> ...
> > +                            else:
> > +                                w_id = f'worker[{worker.id.value_()}]'
> 
> Only BH workers have NULL ->task and they take the POOL_BH branch, so this
> can't be reached. Can we drop it?

Yes, this will be dropped in the next iteration. All non-BH workers have a
valid ->task (and any lockless read fault dereferencing worker.task is
already caught by the retry loop's drgn.FaultError handler).


Kind regards,
-- 
Aaron Tomlin