All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: "yukuai (C)" <yukuai3@huawei.com>
Cc: axboe@kernel.dk, cgroups@vger.kernel.org,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	yi.zhang@huawei.com, zhangxiaoxu5@huawei.com, houtao1@huawei.com
Subject: Re: [RFC PATCH] blk-cgroup: prevent rcu_sched detected stalls warnings in blkg_destroy_all()
Date: Wed, 25 Nov 2020 07:53:12 -0500	[thread overview]
Message-ID: <X75TuKMuO2Ru+rVt@mtj.duckdns.org> (raw)
In-Reply-To: <a24c48a3-6f17-98ac-47ad-770dd7e775ec@huawei.com>

Hello,

On Wed, Nov 25, 2020 at 08:49:19PM +0800, yukuai (C) wrote:
> > You can't continue iteration after dropping both locks. You'd have to jump
> > out of loop and start list_for_each_entry_safe() again.
> 
> Thanks for your review, it's right. On the other hand
> blkcg_activate_policy() and blkcg_deactivate_policy() might have the
> same issue. My idea is that inserting a bookmark to the list, and
> restard from here.

For destruction, as we're destroying the list anyway, we don't need to
insert bookmark and start over from the beginning. For [de]activate policy,
we might need something fancier or change locking so that we can sleep while
iterating. However, policy [de]activations are a lot less of a problem as
they aren't operations which can happen commonly.

> By the way, I found that blk_throtl_update_limit_valid() is called from
> throtl_pd_offline(). If CONFIG_BLK_DEV_THROTTLING_LOW is off, lower
> limit will always be zero, therefor a lot of time will be wasted to
> iterate descendants to find a nonzero lower limit.
> 
> Do you think it's ok to do such modification:

Yeah, sure. Looks fine to me.

Thanks.

-- 
tejun

      reply	other threads:[~2020-11-25 12:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-21  8:34 [RFC PATCH] blk-cgroup: prevent rcu_sched detected stalls warnings in blkg_destroy_all() Yu Kuai
2020-11-21  8:34 ` Yu Kuai
     [not found] ` <20201121083420.3857433-1-yukuai3-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2020-11-25 12:32   ` Tejun Heo
2020-11-25 12:32     ` Tejun Heo
2020-11-25 12:49     ` yukuai (C)
2020-11-25 12:49       ` yukuai (C)
2020-11-25 12:53       ` Tejun Heo [this message]

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=X75TuKMuO2Ru+rVt@mtj.duckdns.org \
    --to=tj@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=cgroups@vger.kernel.org \
    --cc=houtao1@huawei.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai3@huawei.com \
    --cc=zhangxiaoxu5@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 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.