From: Tejun Heo <tj@kernel.org>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Zhao Shuai <zhaoshuai@freebsd.org>,
axboe@kernel.dk, ctalbott@google.com, rni@google.com,
linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
containers@lists.linux-foundation.org
Subject: Re: performance drop after using blkcg
Date: Tue, 11 Dec 2012 08:27:29 -0800 [thread overview]
Message-ID: <20121211162729.GK7084@htj.dyndns.org> (raw)
In-Reply-To: <20121211161820.GE5580@redhat.com>
Hello, Vivek.
On Tue, Dec 11, 2012 at 11:18:20AM -0500, Vivek Goyal wrote:
> - Controlling device queue should bring down throughput too as it
> should bring down level of parallelism at device level. Also asking
> user to tune device queue depth seems bad interface. How would a
> user know what's the right queue depth. May be software can try to
> be intelligent about it and if IO latencies cross a threshold then
> try to decrese queue depth. (We do things like that in CFQ).
Yeah, it should definitely be something automatic. Command completion
latencies are visible to iosched, so it should be doable.
> - Passing prio to device sounds something new and promising. If they
> can do a good job at it, why not. I think at minimum they need to
> make sure READs are prioritized over writes by default. And may
> be provide a way to signal important writes which need to go to
> the disk now.
>
> If READs are prioritized in device, then it takes care of one very
> important use case. Then we just have to worry about other case of
> fairness between different readers or fairness between different
> writers and there we do not idle and try our best to give fair share.
> In case group is not backlogged, it is bound to loose some share.
I think it can be good enough if we have queue at the head / tail
choice. No idea how it'll actually fan out tho.
Thanks.
--
tejun
next prev parent reply other threads:[~2012-12-11 16:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAFVn34SxqAJe_4P-WT8MOiG-kmKKD7ge96zoHXQuGqHWPgAt+A@mail.gmail.com>
2012-12-11 7:00 ` performance drop after using blkcg Zhao Shuai
2013-08-29 3:10 ` joeytao
2013-08-29 3:20 ` joeytao
2012-12-11 14:25 ` Vivek Goyal
2012-12-11 14:27 ` Tejun Heo
2012-12-11 14:43 ` Vivek Goyal
2012-12-11 14:47 ` Tejun Heo
2012-12-11 15:02 ` Vivek Goyal
2012-12-11 15:14 ` Tejun Heo
2012-12-11 15:37 ` Vivek Goyal
2012-12-11 16:01 ` Tejun Heo
2012-12-11 16:18 ` Vivek Goyal
2012-12-11 16:27 ` Tejun Heo [this message]
2012-12-12 7:29 ` Zhao Shuai
2012-12-16 4:38 ` Zhu Yanhai
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=20121211162729.GK7084@htj.dyndns.org \
--to=tj@kernel.org \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=containers@lists.linux-foundation.org \
--cc=ctalbott@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rni@google.com \
--cc=vgoyal@redhat.com \
--cc=zhaoshuai@freebsd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).