Re: [RFC PATCH v13 2/4] blk-iocost: add iocost_ioc_tick tracepoint for per-period device summary

[Tao Cui <cui.tao@linux.dev>]

Hello,

在 2026/11/6 20:56, bot+bpf-ci@kernel.org 写道:
>> blk-iocost: add iocost_ioc_tick tracepoint for per-period device summary
> 
> TL;DR: Commit message only: it restates the code comment instead of giving the
> motivation (monitoring without drgn) for the new iocost_ioc_tick tracepoint.

Right, the changelog ended up restating the code comment.  I'll
rewrite it to lead with the motivation: the tracepoint gives a
per-period summary so monitoring iocost doesn't require drgn.  The
emission semantics stay documented in the code.

Thanks,
Tao
> Not a bug.
> 
>> blk-iocost: add iocost_ioc_tick tracepoint for per-period device summary
>>
>> Add iocost_ioc_tick, emitted once per period from ioc_timer_fn() with
>> the overall controller state: period_us, vrate, busy_level, active iocg
>> count and usage percentage.  busy_level, cur_period, nr_active and
>> usage_us_sum are complete at the emission point.  usage is wall time
>> over wall time, summed over iocgs, and is not capped at 100.  vrate and
>> period_us reflect the current controller state, which an io.cost.qos
>> write may have changed mid-period.
>>
>> The event fires every period the controller is running, including
>> steady states, plus one final tick before the controller goes idle, so
>> the transition to dormancy is directly visible.  The active iocg count
>> is only gathered when the tracepoint is enabled.
>>
>> Suggested-by: Tejun Heo <tj@kernel.org>
>> Signed-off-by: Tao Cui <cuitao@kylinos.cn>
> 
> this isn't a bug, but the middle of the first paragraph ("busy_level,
> cur_period, nr_active and usage_us_sum are complete at the emission point
> ... which an io.cost.qos write may have changed mid-period") restates the
> block comment added above the tracepoint call in ioc_timer_fn() almost word
> for word.
> 
> The reason for adding the event only appears in the comment in
> include/trace/events/iocost.h ("so basic monitoring doesn't require drgn").
> 
> Could the changelog say why a per-period summary event is needed, for
> example the monitoring-without-drgn motivation, rather than repeating the
> code comment?
> 
> 
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> 
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/42219005018