[3/8] blk-iocost: Trace vtime_base_rate instead of vtime_rate
Commit Message
Since commit ac33e91e2daca ("blk-iocost: implement vtime loss
compensation") rename original vtime_base to vtime_base_rate
and current vtime_base is original vtime_base with compensation.
The current rate showed in tracepoint is mixed with vtime_base
and vtime_base_rate:
1) In function ioc_adjust_base_vrate, the first trace_iocost_ioc_vrate_adj
shows vtime_base, the second trace_iocost_ioc_vrate_adj shows
vtime_base_rate.
2) In function iocg_activate shows vtime_base by calling
TRACE_IOCG_PATH(iocg_activate...
3) In function ioc_check_iocgs shows vtime_base by calling
TRACE_IOCG_PATH(iocg_idle...
Trace vtime_base_rate instead of vtime_rate as:
1) Before commit ac33e91e2daca ("blk-iocost: implement vtime loss
compensation"), the traced rate is without compensation, so still
show rate without compensation.
2) The vtime_base_rate is more stable while vtime_rate heavily depends on
excess budeget on current period which may change abruptly in next period.
Signed-off-by: Kemeng Shi <shikemeng@huawei.com>
---
block/blk-iocost.c | 2 +-
include/trace/events/iocost.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
Comments
On Mon, Oct 17, 2022 at 10:00:06AM +0800, Kemeng Shi wrote:
> Since commit ac33e91e2daca ("blk-iocost: implement vtime loss
> compensation") rename original vtime_base to vtime_base_rate
> and current vtime_base is original vtime_base with compensation.
^
vtime_rate
There are multiple places with the same mistake. Can you please fix the
patch description?
> The current rate showed in tracepoint is mixed with vtime_base
> and vtime_base_rate:
> 1) In function ioc_adjust_base_vrate, the first trace_iocost_ioc_vrate_adj
> shows vtime_base, the second trace_iocost_ioc_vrate_adj shows
> vtime_base_rate.
> 2) In function iocg_activate shows vtime_base by calling
> TRACE_IOCG_PATH(iocg_activate...
> 3) In function ioc_check_iocgs shows vtime_base by calling
> TRACE_IOCG_PATH(iocg_idle...
>
> Trace vtime_base_rate instead of vtime_rate as:
> 1) Before commit ac33e91e2daca ("blk-iocost: implement vtime loss
> compensation"), the traced rate is without compensation, so still
> show rate without compensation.
> 2) The vtime_base_rate is more stable while vtime_rate heavily depends on
> excess budeget on current period which may change abruptly in next period.
>
> Signed-off-by: Kemeng Shi <shikemeng@huawei.com>
Other than that,
Acked-by: Tejun Heo <tj@kernel.org>
Thanks.
@@ -977,7 +977,7 @@ static void ioc_adjust_base_vrate(struct ioc *ioc, u32 rq_wait_pct,
if (!ioc->busy_level || (ioc->busy_level < 0 && nr_lagging)) {
if (ioc->busy_level != prev_busy_level || nr_lagging)
- trace_iocost_ioc_vrate_adj(ioc, atomic64_read(&ioc->vtime_rate),
+ trace_iocost_ioc_vrate_adj(ioc, vrate,
missed_ppm, rq_wait_pct,
nr_lagging, nr_shortages);
@@ -38,7 +38,7 @@ DECLARE_EVENT_CLASS(iocost_iocg_state,
__assign_str(cgroup, path);
__entry->now = now->now;
__entry->vnow = now->vnow;
- __entry->vrate = now->vrate;
+ __entry->vrate = iocg->ioc->vtime_base_rate;
__entry->last_period = last_period;
__entry->cur_period = cur_period;
__entry->vtime = vtime;
@@ -160,7 +160,7 @@ TRACE_EVENT(iocost_ioc_vrate_adj,
TP_fast_assign(
__assign_str(devname, ioc_name(ioc));
- __entry->old_vrate = atomic64_read(&ioc->vtime_rate);
+ __entry->old_vrate = ioc->vtime_base_rate;
__entry->new_vrate = new_vrate;
__entry->busy_level = ioc->busy_level;
__entry->read_missed_ppm = missed_ppm[READ];