linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Suresh Jayaraman <sjayaraman@suse.com>,
	lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	Fengguang Wu <fengguang.wu@intel.com>,
	Andrea Righi <andrea@betterlinux.com>, Jan Kara <jack@suse.cz>,
	Moyer Jeff Moyer <jmoyer@redhat.com>
Subject: Re: [LSF/MM TOPIC] [ATTEND] Throttling I/O
Date: Fri, 25 Jan 2013 10:33:34 -0800	[thread overview]
Message-ID: <20130125183334.GL3081@htj.dyndns.org> (raw)
In-Reply-To: <20130125182639.GF6197@redhat.com>

Hey,

On Fri, Jan 25, 2013 at 01:26:39PM -0500, Vivek Goyal wrote:
> How many of these spindle drives are not behind some kind of hardware
> raid or on SAN network. Becaue any aggregation of spindle drives by
> hardware/external entity makes group scheduling not worth it very soon.

Hmmm?  Sure, enterprise storage is usually behind some SAN silliness,
but if you go larger scale, e.g. the "cloud" stuff, people usually go
for the most economic solution - ie. some spindles per machine.  At
least the ones I know do.

> > For example, google has been using half-hacky hierarchical writeback
> > support in cfq for quite some time now and they'll switch to upstream
> > implementation once we get it working, so I don't think it's a wasted
> > effort.
> 
> I guess apart from google I have not heard anybody else using it
> successfully and that's when I get skeptic about it. May be once the
> support for buffered write control is in, things will be better. Because,
> that's the biggest offending workload people want to protect against.

Yeah, I think it's mostly because we don't support it and there aren't
too many organizations with enough muscle to implement and maintain
their own hierarchical iosched and mutilations to writeback path.
Given the workloads these servers have to run, some form of io
resource control is just necessary.

Thanks.

-- 
tejun

  reply	other threads:[~2013-01-25 18:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-25 13:19 [LSF/MM TOPIC] [ATTEND] Throttling I/O Suresh Jayaraman
2013-01-25 16:34 ` Vivek Goyal
2013-01-25 17:52   ` Tejun Heo
2013-01-25 18:26     ` Vivek Goyal
2013-01-25 18:33       ` Tejun Heo [this message]
2013-01-28 11:16   ` Suresh Jayaraman
2013-01-28 19:24     ` Tejun Heo
2013-01-25 17:57 ` Tejun Heo
2013-01-28 11:46   ` Suresh Jayaraman

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=20130125183334.GL3081@htj.dyndns.org \
    --to=tj@kernel.org \
    --cc=andrea@betterlinux.com \
    --cc=fengguang.wu@intel.com \
    --cc=jack@suse.cz \
    --cc=jmoyer@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=sjayaraman@suse.com \
    --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).