From: Tejun Heo <tj@kernel.org>
To: Wang Jianchao <jianchao.wan9@gmail.com>
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: Thu, 13 Jan 2022 07:01:31 -1000 [thread overview]
Message-ID: <YeBa68w4nQQvBM9Z@slm.duckdns.org> (raw)
In-Reply-To: <faafdf29-6d8b-82a8-c69d-4ab3e623b489@gmail.com>
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.
> 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.
--
tejun
next prev parent reply other threads:[~2022-01-13 17:01 UTC|newest]
Thread overview: 25+ 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 1:49 ` kernel test robot
2022-01-13 3:52 ` Wang Jianchao
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 [this message]
2022-01-14 2:01 ` Wang Jianchao
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=YeBa68w4nQQvBM9Z@slm.duckdns.org \
--to=tj@kernel.org \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=jbacik@fb.com \
--cc=jianchao.wan9@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.