From: Tejun Heo <tj@kernel.org>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Michal Hocko <mhocko@suse.cz>,
cgroups@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Sha Zhengju <handai.szj@gmail.com>,
devel@openvz.org, Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH RFC] fsio: filesystem io accounting cgroup
Date: Tue, 9 Jul 2013 20:50:24 -0700 [thread overview]
Message-ID: <20130710035024.GA28461@htj.dyndns.org> (raw)
In-Reply-To: <20130710030955.GA3569@redhat.com>
Hello,
On Tue, Jul 09, 2013 at 11:09:55PM -0400, Vivek Goyal wrote:
> Stacking drivers are pretty important ones and we expect throttling
> to work with them. By throttling bio, a single hook worked both for
> request based drivers and bio based drivers.
Oh yeah, sure, we have them working now, so there's no way to break
them but that doesn't mean it's a good overall design. I don't have a
good answer for this one. The root cause is having the distinction
between bio and rq based drivers. With the right constructs, I
suspect we probably could have done away with bio based drivers, but,
well, that's all history now.
> So looks like for bio based drivers you want bio throttling and for
> request based drviers, request throttling and define a separate hook
> in blk_queue_bio(). A generic hook probably can check the type of request
> queue and not throttle bio if it is request based queue and ultimately
> request queue based hook will throttle it.
>
> So in a cgroup we blkio.throttle.io_serviced will have stats for
> bio/request depending on type of device.
>
> And we will need to modify throttling logic so that it can handle
> both bio and request throttling. Not sure how much of code can be
> shared for bio/request throttling.
I'm not sure how much (de)multiplexing and sharing we'd be doing but
I'm afraid there's gonna need to be some. We really can't use the
same logic for SSDs and rotating rusts after all and it probably would
be best to avoid contaminating SSD paths with lots of guesstimating
logics necessary for rotating rusts.
> I am not sure about request based multipath driver and it might
> require some special handling.
If it's not supported now, I'll be happy with just leaving it alone
and telling mp users to configure the underlying queues.
> Is it roughly inline with what you have been thinking.
I'm hoping to keep it somewhat manageable at least. I wouldn't mind
leaving stacking driver and cfq-iosched support as they are while only
supporting SSD devices with new code. It's all pie in the sky at this
point and none of this matters before we fix the bdi and writeback
issue anyway.
Thanks.
--
tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2013-07-10 3:50 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-08 10:01 [PATCH RFC] fsio: filesystem io accounting cgroup Konstantin Khlebnikov
2013-07-08 17:00 ` Tejun Heo
2013-07-08 17:52 ` Vivek Goyal
2013-07-08 17:56 ` Tejun Heo
2013-07-09 8:28 ` Konstantin Khlebnikov
2013-07-09 12:57 ` Tejun Heo
2013-07-09 13:15 ` Konstantin Khlebnikov
2013-07-09 13:16 ` Tejun Heo
2013-07-09 13:16 ` Tejun Heo
2013-07-09 13:43 ` Konstantin Khlebnikov
2013-07-09 13:45 ` Tejun Heo
2013-07-09 14:18 ` Vivek Goyal
2013-07-09 14:29 ` Tejun Heo
2013-07-09 14:54 ` Vivek Goyal
2013-07-09 15:08 ` Tejun Heo
[not found] ` <20130710030955.GA3569@redhat.com>
2013-07-10 3:50 ` Tejun Heo [this message]
2013-07-09 14:35 ` Konstantin Khlebnikov
2013-07-09 14:42 ` Tejun Heo
2013-07-09 15:06 ` Vivek Goyal
2013-07-09 17:42 ` Konstantin Khlebnikov
2013-07-09 18:35 ` Vivek Goyal
2013-07-09 20:54 ` Konstantin Khlebnikov
2013-07-08 18:11 ` Vivek Goyal
2013-07-09 15:39 ` Theodore Ts'o
2013-07-09 17:12 ` Konstantin Khlebnikov
-- strict thread matches above, loose matches on Subject: below --
2013-07-08 9:59 Konstantin Khlebnikov
2013-07-10 4:43 ` Sha Zhengju
2013-07-10 6:03 ` Konstantin Khlebnikov
2013-07-10 8:37 ` Sha Zhengju
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=20130710035024.GA28461@htj.dyndns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=devel@openvz.org \
--cc=handai.szj@gmail.com \
--cc=khlebnikov@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--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;
as well as URLs for NNTP newsgroup(s).