From: Tejun Heo <tj@kernel.org>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: axboe@kernel.dk, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org, avanzini.arianna@gmail.com,
device-mapper development <dm-devel@redhat.com>
Subject: Re: [PATCH 8/8] cfq-iosched: charge async IOs to the appropriate blkcg's instead of the root
Date: Tue, 9 Jun 2015 12:11:34 +0900 [thread overview]
Message-ID: <20150609031134.GM21465@mtj.duckdns.org> (raw)
In-Reply-To: <20150608222904.GB20918@redhat.com>
Hey, Vivek.
On Mon, Jun 08, 2015 at 06:29:04PM -0400, Vivek Goyal wrote:
...
> But above is not true for buffered writes, we will not associate io
> context. Instead only cgroup information will be sent down and io
> context of submitter will be used.
>
> So any thread which is forced to submit buffered write for some other
> cgroup, will have its sync queue also reset (Because CFQ will think
Yeah, it'll usually be the writeback work items.
> that cgroup of submitter has changed). Not sure how often it will happen,
> but if it happens frequenty, this might show up in profiles. I had
They're unlikely to have sync queues associated with them to begin
with and even when the context gets reset each iteration should be big
enough to drown this sort of overhead. Writeback operates in a fairly
sizable chunks.
> mentioned this in the past and IIUC you said we will have to carry
> writeback information all the way into lower layers. May be that's
> an optimzation for later. So nothing new here, just trying to understand
> the current situation.
I'm actually kinda doubtful about caching async queues on cic at all.
We already perform most of operations necessary to lookup the async
queue for check_blkcg_changed(). We might as well just look up and
pin each time.
> Also I am wondring if this cgroup and io context information is carried
> through dm layer or not. I guess it might be a separate discussion. It
> has come for discussion internally in the past. So this might be a good
> time to get attention of dm developers on these upcoming changes. (CC dm-devel).
Hmmm... it depends on what dm does with the bio. It can surely
propagate the cgroup information through sub bios.
Thanks.
--
tejun
next prev parent reply other threads:[~2015-06-09 3:11 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-08 8:59 [PATCHSET block/for-4.2/writeback] block, cgroup: make cfq charge async IOs to the appropriate blkcgs Tejun Heo
2015-06-08 8:59 ` [PATCH 1/8] cfq-iosched: simplify control flow in cfq_get_queue() Tejun Heo
2015-06-08 18:36 ` Jeff Moyer
2015-06-08 8:59 ` [PATCH 2/8] cfq-iosched: fix async oom queue handling Tejun Heo
2015-06-08 18:42 ` Jeff Moyer
2015-06-08 8:59 ` [PATCH 3/8] cfq-iosched: fix oom cfq_queue ref leak in cfq_set_request() Tejun Heo
2015-06-08 18:51 ` Jeff Moyer
2015-06-08 8:59 ` [PATCH 4/8] cfq-iosched: minor cleanups Tejun Heo
2015-06-08 18:59 ` Jeff Moyer
2015-06-08 8:59 ` [PATCH 5/8] cfq-iosched: remove @gfp_mask from cfq_find_alloc_queue() Tejun Heo
2015-06-08 19:24 ` Jeff Moyer
2015-06-08 20:27 ` Jeff Moyer
2015-06-08 21:19 ` Vivek Goyal
2015-06-09 3:01 ` Tejun Heo
2015-06-09 3:00 ` Tejun Heo
2015-06-09 14:29 ` Jeff Moyer
2015-06-08 8:59 ` [PATCH 6/8] cfq-iosched: move cfq_group determination from cfq_find_alloc_queue() to cfq_get_queue() Tejun Heo
2015-06-09 14:32 ` Jeff Moyer
2015-06-08 8:59 ` [PATCH 7/8] cfq-iosched: fold cfq_find_alloc_queue() into cfq_get_queue() Tejun Heo
2015-06-09 14:40 ` Jeff Moyer
2015-06-10 2:47 ` Tejun Heo
2015-06-08 8:59 ` [PATCH 8/8] cfq-iosched: charge async IOs to the appropriate blkcg's instead of the root Tejun Heo
2015-06-08 22:29 ` Vivek Goyal
2015-06-09 3:11 ` Tejun Heo [this message]
2015-06-09 15:03 ` Jeff Moyer
2015-06-08 19:49 ` [PATCHSET block/for-4.2/writeback] block, cgroup: make cfq charge async IOs to the appropriate blkcgs Jeff Moyer
2015-06-09 3:03 ` Tejun Heo
2015-06-09 15:05 ` Jeff Moyer
2015-06-10 2:49 ` Tejun Heo
2015-06-09 4:21 ` [PATCH 4.5/8] blkcg, cfq-iosched: use GFP_NOWAIT instead of GFP_ATOMIC for non-critical allocations Tejun Heo
2015-06-09 14:27 ` Jeff Moyer
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=20150609031134.GM21465@mtj.duckdns.org \
--to=tj@kernel.org \
--cc=avanzini.arianna@gmail.com \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=dm-devel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@redhat.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
all inboxes | Powered by JetHome®