linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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 07:29:08 -0700	[thread overview]
Message-ID: <20130709142908.GE2478@htj.dyndns.org> (raw)
In-Reply-To: <20130709141833.GA2237@redhat.com>

On Tue, Jul 09, 2013 at 10:18:33AM -0400, Vivek Goyal wrote:
> For implementing throttling one as such does not have to do time
> slice management on the queue.  For providing constructs like IOPS
> or bandwidth throttling, one just need to put one throttling knob 
> in the cgroup pipe irrespective of time slice management on the
> backing device/network.

We should be providing a comprehensive mechanism to be used from
userland, not something which serves pieces of specialized
requirements here and there.  blkio is already a mess with the
capability changing depending on which elevator is in use and
blk-throttle counting bios instead of merged requests making iops
control a bit silly.  We need to clean that up, not add more mess on
top.

> Also time slice management is one way of managing the backend resource.
> CFQ did that and it works only for slow devices. For faster devices
> we anyway need some kind of token mechanism instead of keeping track
> of time.

No, it is the *right* resource to manage for rotating devices if you
want any sort of meaningful proportional resource distribution.  It's
not something one dreams up out of blue but something which arises
from the fundamental operating characteristics of the device.  For
SSDs, iops is good enough as their latency profile is consistent
enough but doing so with rotating disks doesn't yield anything useful.

> So I don't think trying to manage time slice is the requirement here.

For a cgroup resource controller, it *is* a frigging requirement to
control the right fundamental resource at the right place where the
resource resides and can be fully controlled.  Nobody should have any
other impression.

> > and by the time you implemented proper hierarchy support and
> > proportional contnrol, yours isn't gonna be that simple either.
> 
> I suspect he is not plannnig to do any proportional control at that
> layer. Just throttling mechanism.

blkio should be able to do proportional control in general.  The fact
that we aren't able to do that except when cfq-iosched is in use is a
problem which needs to be fixed.  It's not a free-for-all pass for
creating more broken stuff.

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>

  reply	other threads:[~2013-07-09 14:29 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 [this message]
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
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=20130709142908.GE2478@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).