From: Wang Jianchao <jianchao.wan9@gmail.com>
To: Tejun Heo <tj@kernel.org>
Cc: axboe@kernel.dk, jbacik@fb.com, bvanassche@acm.org,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 13/13] blk: introduce iostat per cgroup module
Date: Fri, 14 Jan 2022 10:01:31 +0800 [thread overview]
Message-ID: <13cad320-db43-99db-ed0c-61b27a9a3447@gmail.com> (raw)
In-Reply-To: <YeBa68w4nQQvBM9Z@slm.duckdns.org>
Hi Tejun
Thanks so much your comment :)
I really appreciate it.
On 2022/1/14 1:01 上午, Tejun Heo wrote:
> Hello,
>
> On Thu, Jan 13, 2022 at 10:40:27AM +0800, Wang Jianchao wrote:
>> bw/iops/lat of data or metadata of one cgroup is very basic statistics
>
> bw and iops can already be derived from the cumulative counters in io.stat.
> Latencies without distribution are often what we tradtionally exposed not
> because they're great but because exposing distributions is so cumbersome
> from kernel. Also, latency numbers at cgroup level isn't *that* useful
> anyway. There isn't a lot you can deduce for the particular cgroup from that
> number.
I agree with this. But my customer would yell at me because they really want to
see that....
>
>> which kernel could provide especially when cgroup is employed everywhere.
>> And we love to collect them all the time during the instance in cgroup is
>> running.
>
> It's really not that difficult to collect these numbers from bpf with pretty
> low overhead. There's the problem of deployment for which there isn't "the"
> right and convenient way but it'd be more worthwhile to put efforts towards
> that.
>
>>> What if I want to know what portions are random, or the
>>> distribution of IO sizes?
>> This looks really detailed statistics :)
>>> Do I add another rq-qos policy or add another
>>> interface file with interface versioning?
>> This iostat module can not provide all the kinds of statistics we want
>> but just some very basic things. And maybe it can provide better hooks
>> to install the ebpf program to collect detailed statistics.
>
> I mean, "really basic" means different things for different folks. Bytes /
> ios, we all seem to agree. Beyond that, who knows? There already are enough
> hooks to collect stats that you're trying to collect. The examples in py-bcc
> might be a good place to start.
Thanks for your suggestion. I will read it and try with bpf
Best Regards
Jianchao
next prev parent reply other threads:[~2022-01-14 2:01 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-10 9:10 [PATCH 0/13] blk: make blk-rq-qos policies pluggable and modular Wang Jianchao
2022-01-10 9:10 ` [PATCH 01/13] blk: make blk-rq-qos support pluggable and modular policy Wang Jianchao
2022-01-13 1:49 ` kernel test robot
2022-01-13 3:52 ` Wang Jianchao
2022-01-10 9:10 ` [PATCH 02/13] blk-wbt: make wbt pluggable Wang Jianchao
2022-01-10 9:10 ` [PATCH 03/13] blk: export following interfaces Wang Jianchao
2022-01-10 9:10 ` [PATCH 04/13] cgroup: export following two interfaces Wang Jianchao
2022-01-10 9:10 ` [PATCH 05/13] blk-iolatency: make iolatency pluggable and modular Wang Jianchao
2022-01-10 9:10 ` [PATCH 06/13] blk: remove unused BLK_RQ_IO_DATA_LEN Wang Jianchao
2022-01-10 9:10 ` [PATCH 07/13] blk: use standalone macro to control bio.bi_iocost_cost Wang Jianchao
2022-01-10 9:10 ` [PATCH 08/13] blk-iocost: make iocost pluggable and modular Wang Jianchao
2022-01-10 9:10 ` [PATCH 09/13] blk: rename ioprio.c to ioprio-common.c Wang Jianchao
2022-01-10 9:10 ` [PATCH 10/13] blk-ioprio: make ioprio pluggable and modular Wang Jianchao
2022-01-10 9:10 ` [PATCH 11/13] blk: remove unused interfaces of blk-rq-qos Wang Jianchao
2022-01-10 9:10 ` [PATCH 12/13] blk: make request able to carry blkcg_gq Wang Jianchao
2022-01-10 9:10 ` [PATCH 13/13] blk: introduce iostat per cgroup module Wang Jianchao
2022-01-12 20:13 ` Tejun Heo
2022-01-13 2:40 ` Wang Jianchao
2022-01-13 17:01 ` Tejun Heo
2022-01-14 2:01 ` Wang Jianchao [this message]
2022-01-10 17:36 ` [PATCH 0/13] blk: make blk-rq-qos policies pluggable and modular Christoph Hellwig
2022-01-11 1:53 ` Wang Jianchao
2022-01-11 3:25 ` Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=13cad320-db43-99db-ed0c-61b27a9a3447@gmail.com \
--to=jianchao.wan9@gmail.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=jbacik@fb.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®