From: Tejun Heo <tj@kernel.org>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: hch@infradead.org, josef@toxicpanda.com, axboe@kernel.dk,
cgroups@vger.kernel.org, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, yi.zhang@huawei.com,
"yukuai (C)" <yukuai3@huawei.com>
Subject: Re: [PATCH v2 1/2] blk-iocost: add refcounting for iocg
Date: Thu, 12 Jan 2023 14:53:42 -1000 [thread overview]
Message-ID: <Y8CrloCDGhbU42OH@slm.duckdns.org> (raw)
In-Reply-To: <4aeef320-c6c8-d9b4-8826-d58f00ea6264@huaweicloud.com>
Hello,
On Thu, Jan 12, 2023 at 02:18:15PM +0800, Yu Kuai wrote:
> remove the blkcg_deactivate_policy() from rq_qos_exit() from deleting
> the device, and delay the policy cleanup and free to blkg_destroy_all().
> Then the policies(other than bfq) can only call pd_free_fn() from
> blkg_destroy(), and it's easy to guarantee the order. For bfq, it can
> stay the same since bfq has refcounting itself.
>
> Then for the problem that ioc can be freed in pd_free_fn(), we can fix
> it by freeing ioc in ioc_pd_free() for root blkg instead of
> rq_qos_exit().
>
> What do you think?
That would remove the ability to dynamically remove an rq_qos policy, right?
We don't currently do it but given that having an rq_qos registered comes
with perf overhead, it's something we might want to do in the future - e.g.
only activate the policy when the controller is actually enabled. So, idk.
What's wrong with synchronizing the two removal paths? blkcg policies are
combinations of cgroups and block device configurations, so having exit
paths from both sides is kinda natural.
Thanks.
--
tejun
next prev parent reply other threads:[~2023-01-13 0:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-27 12:55 [PATCH v2 0/2] blk-iocost: add refcounting for iocg and ioc Yu Kuai
2022-12-27 12:55 ` [PATCH v2 1/2] blk-iocost: add refcounting for iocg Yu Kuai
2023-01-04 21:44 ` Tejun Heo
2023-01-05 1:14 ` Yu Kuai
2023-01-05 18:32 ` Tejun Heo
2023-01-06 1:08 ` Yu Kuai
2023-01-06 20:18 ` Tejun Heo
2023-01-09 1:32 ` Yu Kuai
2023-01-09 18:23 ` Tejun Heo
2023-01-10 1:39 ` Yu Kuai
2023-01-10 18:36 ` Tejun Heo
2023-01-11 1:36 ` Yu Kuai
2023-01-11 17:07 ` Tejun Heo
2023-01-12 6:18 ` Yu Kuai
2023-01-13 0:53 ` Tejun Heo [this message]
2023-01-13 1:10 ` Yu Kuai
2023-01-13 1:15 ` Tejun Heo
2023-01-13 1:25 ` Yu Kuai
2023-01-13 17:16 ` Tejun Heo
2023-01-16 3:25 ` Yu Kuai
2022-12-27 12:55 ` [PATCH v2 2/2] blk-iocost: add refcounting for ioc Yu Kuai
2023-01-04 21:45 ` Tejun Heo
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=Y8CrloCDGhbU42OH@slm.duckdns.org \
--to=tj@kernel.org \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=hch@infradead.org \
--cc=josef@toxicpanda.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yi.zhang@huawei.com \
--cc=yukuai1@huaweicloud.com \
--cc=yukuai3@huawei.com \
/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