From: Tejun Heo <tj@kernel.org>
To: Josef Bacik <josef@toxicpanda.com>
Cc: axboe@kernel.dk, kernel-team@fb.com, linux-block@vger.kernel.org,
akpm@linux-foundation.org, linux-mm@kvack.org,
hannes@cmpxchg.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Josef Bacik <jbacik@fb.com>
Subject: Re: [PATCH 06/13] blkcg: add generic throttling mechanism
Date: Wed, 30 May 2018 09:26:29 -0700 [thread overview]
Message-ID: <20180530162629.GN1351649@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <20180529211724.4531-7-josef@toxicpanda.com>
Hello,
On Tue, May 29, 2018 at 05:17:17PM -0400, Josef Bacik wrote:
> +static void blkcg_scale_delay(struct blkcg_gq *blkg, u64 now)
> +{
> + u64 old = atomic64_read(&blkg->delay_start);
> +
> + if (old + NSEC_PER_SEC <= now &&
Maybe time_before64()?
> + atomic64_cmpxchg(&blkg->delay_start, old, now) == old) {
> + u64 cur = atomic64_read(&blkg->delay_nsec);
> + u64 sub = min_t(u64, blkg->last_delay, now - old);
> + int cur_use = atomic_read(&blkg->use_delay);
> +
> + if (cur_use < blkg->last_use)
> + sub = max_t(u64, sub, blkg->last_delay >> 1);
> +
> + /* This shouldn't happen, but handle it anyway. */
> + if (unlikely(cur < sub)) {
> + atomic64_set(&blkg->delay_nsec, 0);
> + blkg->last_delay = 0;
> + } else {
> + atomic64_sub(sub, &blkg->delay_nsec);
> + blkg->last_delay = cur - sub;
> + }
> + blkg->last_use = cur_use;
Can you please add some comments explaining the above? It's a lot of
logic.
> +static void blkcg_maybe_throttle_blkg(struct blkcg_gq *blkg, bool use_memdelay)
> +{
Maybe add a comment explaining that this is a cold path?
> + u64 now = ktime_to_ns(ktime_get());
> + u64 exp;
> + u64 delay_nsec = 0;
> + int tok;
> +
> + while (blkg->parent) {
> + if (atomic_read(&blkg->use_delay)) {
> + blkcg_scale_delay(blkg, now);
> + delay_nsec = max_t(u64, delay_nsec,
> + atomic64_read(&blkg->delay_nsec));
> + }
> + blkg = blkg->parent;
> + }
Cuz the above may look too much otherwise.
...
> +void blkcg_maybe_throttle_current(void)
> +{
> + struct request_queue *q = current->throttle_queue;
> + struct cgroup_subsys_state *css;
> + struct blkcg *blkcg;
> + struct blkcg_gq *blkg;
> + bool use_memdelay = current->use_memdelay;
> +
> + if (!q)
> + return;
The above would be the path taken in most cases, right?
> +
> + current->throttle_queue = NULL;
> + current->use_memdelay = false;
So, we only wait once, capped to 1s per blkcg_schedule_throttle()?
It'd be great to document the rationales.
> + rcu_read_lock();
> + css = kthread_blkcg();
> + if (css)
> + blkcg = css_to_blkcg(css);
> + else
> + blkcg = css_to_blkcg(task_css(current, io_cgrp_id));
> +
> + if (!blkcg)
> + goto out;
> + blkg = blkg_lookup(blkcg, q);
> + if (!blkg)
> + goto out;
> + blkg_get(blkg);
I don't think we can do blkg_get() on a blkg which is only protected
by rcu. We probably need blkg_tryget() here.
> + rcu_read_unlock();
> + blk_put_queue(q);
> +
> + blkcg_maybe_throttle_blkg(blkg, use_memdelay);
> + blkg_put(blkg);
> + return;
> +out:
> + rcu_read_unlock();
> + blk_put_queue(q);
> +}
> +EXPORT_SYMBOL_GPL(blkcg_maybe_throttle_current);
> +
> +void blkcg_schedule_throttle(struct request_queue *q, bool use_memdelay)
> +{
> + if (unlikely(current->flags & PF_KTHREAD))
> + return;
> +
> + if (!blk_get_queue(q))
> + return;
> +
> + if (current->throttle_queue)
> + blk_put_queue(current->throttle_queue);
> + current->throttle_queue = q;
Can't we set current->throttle_blkg directly?
> +static inline int blkcg_unuse_delay(struct blkcg_gq *blkg)
> +{
> + int old = atomic_read(&blkg->use_delay);
> +
> + if (old == 0)
> + return 0;
> +
> + while (old) {
> + int cur = atomic_cmpxchg(&blkg->use_delay, old, old - 1);
Can we use atomic_dec_return() here?
> + if (cur == old)
> + break;
> + cur = old;
> + }
> +
> + if (old == 0)
> + return 0;
> + if (old == 1)
> + atomic_dec(&blkg->blkcg->css.cgroup->congestion_count);
> + return 1;
> +}
> +
> +static inline void blkcg_clear_delay(struct blkcg_gq *blkg)
> +{
> + int old = atomic_read(&blkg->use_delay);
> + if (!old)
> + return;
> + if (atomic_cmpxchg(&blkg->use_delay, old, 0) == old)
> + atomic_dec(&blkg->blkcg->css.cgroup->congestion_count);
atomic_add_unless()?
Thanks.
--
tejun
next prev parent reply other threads:[~2018-05-30 16:26 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-29 21:17 [PATCH 00/13] Introdue io.latency io controller for cgroups Josef Bacik
2018-05-29 21:17 ` [PATCH 01/13] block: add bi_blkg to the bio " Josef Bacik
2018-05-30 15:49 ` Tejun Heo
2018-05-29 21:17 ` [PATCH 02/13] block: introduce bio_issue_as_root_blkg Josef Bacik
2018-05-30 15:53 ` Tejun Heo
2018-05-29 21:17 ` [PATCH 03/13] blk-cgroup: allow controllers to output their own stats Josef Bacik
2018-05-30 15:54 ` Tejun Heo
2018-05-29 21:17 ` [PATCH 04/13] blk: introduce REQ_SWAP Josef Bacik
2018-05-30 15:58 ` Tejun Heo
2018-05-29 21:17 ` [PATCH 05/13] swap,blkcg: issue swap io with the appropriate context Josef Bacik
2018-05-30 13:06 ` Johannes Weiner
2018-05-30 16:05 ` Tejun Heo
2018-05-29 21:17 ` [PATCH 06/13] blkcg: add generic throttling mechanism Josef Bacik
2018-05-30 13:11 ` Johannes Weiner
2018-05-30 16:26 ` Tejun Heo [this message]
2018-05-29 21:17 ` [PATCH 07/13] memcontrol: schedule throttling if we are congested Josef Bacik
2018-05-30 14:15 ` Johannes Weiner
2018-05-29 21:17 ` [PATCH 08/13] blk-stat: export helpers for modifying blk_rq_stat Josef Bacik
2018-05-30 16:31 ` Tejun Heo
2018-05-29 21:17 ` [PATCH 09/13] blk-rq-qos: refactor out common elements of blk-wbt Josef Bacik
2018-05-29 21:17 ` [PATCH 10/13] block: remove external dependency on wbt_flags Josef Bacik
2018-05-29 21:17 ` [PATCH 11/13] rq-qos: introduce dio_bio callback Josef Bacik
2018-05-29 21:17 ` [PATCH 12/13] block: introduce blk-iolatency io controller Josef Bacik
2018-05-29 22:07 ` Randy Dunlap
2018-05-30 16:40 ` Tejun Heo
2018-05-29 21:17 ` [PATCH 13/13] Documentation: add a doc for blk-iolatency Josef Bacik
2018-05-30 16:44 ` Tejun Heo
2018-05-30 18:32 ` Randy Dunlap
-- strict thread matches above, loose matches on Subject: below --
2018-06-05 13:29 [PATCH 00/13][V2] Introduce io.latency io controller for cgroups Josef Bacik
2018-06-05 13:29 ` [PATCH 06/13] blkcg: add generic throttling mechanism Josef Bacik
2018-06-05 20: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=20180530162629.GN1351649@devbig577.frc2.facebook.com \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=hannes@cmpxchg.org \
--cc=jbacik@fb.com \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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.