From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Tejun Heo <tj@kernel.org>
Cc: Kent Overstreet <kmo@daterainc.com>, Jens Axboe <axboe@kernel.dk>,
Christoph Hellwig <hch@lst.de>,
"linux-kernel@vger.kernel.org >> Linux Kernel Mailing List"
<linux-kernel@vger.kernel.org>,
linux-s390 <linux-s390@vger.kernel.org>
Subject: blk-mq vs cpu hotplug performance (due to percpu_ref_put performance)
Date: Tue, 28 Oct 2014 20:35:39 +0100 [thread overview]
Message-ID: <544FF00B.8050403@de.ibm.com> (raw)
Tejun,
when going from 3.17 to 3.18-rc2 cpu hotplug become horrible slow on some KVM guests on s390
I was able to bisect this to
commit 9eca80461a45177e456219a9cd944c27675d6512
("Revert "blk-mq, percpu_ref: implement a kludge for SCSI blk-mq stall during probe")
Seems that this is due to all the rcu grace periods on percpu_ref_put during the cpu hotplug notifiers.
This is barely noticable on small guests (lets say 1 virtio disk), but on guests with 20 disks a hotplug takes 2 or 3 instead of around 0.1 sec.
There are three things that make this especially noticably on s390:
- s390 has 100HZ which makes grace period waiting slower
- s390 does not yet implement context tracking which would speed up RCU
- s390 systems usually have a bigger amount of disk (e.g. 20 7GB disks instead of one 140GB disks)
Any idea how to improve the situation? I think we could accept an expedited variant on cpu hotplug, since stop_machine_run will cause hickups anyway, but there are probably other callers.
Christian
PS: on the plus side, this makes CPU hotplug races less likely....
next reply other threads:[~2014-10-28 19:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-28 19:35 Christian Borntraeger [this message]
2014-10-28 20:00 ` blk-mq vs cpu hotplug performance (due to percpu_ref_put performance) Tejun Heo
2014-10-28 20:20 ` Christian Borntraeger
2014-10-28 20:22 ` Tejun Heo
2014-10-28 20:26 ` Tejun Heo
2014-10-28 20:29 ` Christian Borntraeger
2014-10-28 20:30 ` Tejun Heo
2014-11-04 18:52 ` [PATCH block/for-linus] blk-mq: make mq_queue_reinit_notify() freeze queues in parallel Tejun Heo
2014-11-04 19:46 ` Christian Borntraeger
2014-11-04 21:48 ` Jens Axboe
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=544FF00B.8050403@de.ibm.com \
--to=borntraeger@de.ibm.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=kmo@daterainc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@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 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.