[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a574532a-c6c4-48cb-9081-34c918e950a0@acm.org>
Date: Mon, 17 Jun 2024 14:30:42 -0700
From: Bart Van Assche <bvanassche@....org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: dongliang cui <cuidongliang390@...il.com>,
Dongliang Cui <dongliang.cui@...soc.com>, axboe@...nel.dk,
mhiramat@...nel.org, mathieu.desnoyers@...icios.com, ebiggers@...nel.org,
ke.wang@...soc.com, hongyu.jin.cn@...il.com, niuzhiguo84@...il.com,
hao_hao.wang@...soc.com, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org, akailash@...gle.com
Subject: Re: [PATCH v5] block: Add ioprio to block_rq tracepoint
On 6/17/24 10:07 AM, Steven Rostedt wrote:
> On Mon, 17 Jun 2024 10:02:48 -0700
> Bart Van Assche <bvanassche@....org> wrote:
>
>>>> Do we really want to include the constant "[0]" in the tracing output?
>>> This is how it is printed in the source code.
>>> From the code flow point of view, there is no need to print this value
>>> in trace_block_rq_requeue.
>>> Do we need to consider the issue of uniform printing format? If not, I
>>> think we can delete it.
>>
>> I'm not aware of any other tracing statement that prints out a constant.
>> Is there perhaps something that I'm missing or overlooking?
>
> The only time that is done, is if the trace event is used in multiple
> places and there's one place that the value will always be the same.
Thanks for the clarification Steven.
Hence:
Reviewed-by: Bart Van Assche <bvanassche@....org>
Powered by blists - more mailing lists