linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Andrea Righi <andrea@betterlinux.com>
Cc: Fengguang Wu <fengguang.wu@intel.com>,
	Suresh Jayaraman <sjayaraman@suse.com>,
	lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org, Jan Kara <jack@suse.cz>,
	Greg Thelen <gthelen@google.com>
Subject: Re: [ATTEND] [LSF/MM TOPIC] Buffered writes throttling
Date: Wed, 7 Mar 2012 15:26:16 -0500	[thread overview]
Message-ID: <20120307202616.GJ13430@redhat.com> (raw)
In-Reply-To: <20120306004602.GA16061@thinkpad>

On Tue, Mar 06, 2012 at 01:46:02AM +0100, Andrea Righi wrote:

[..]
> > > > Good point. balance_dirty_pages() has no idea about the devices at
> > > > all. So the rate limit for buffered writes can hardly be unified with
> > > > the per-device rate limit for direct writes.
> > > > 
> > > 
> > > I think balance_dirty_pages() can have an idea about devices. We can get
> > > a reference to the right block device / request queue from the
> > > address_space:
> > > 
> > >   bdev = mapping->host->i_sb->s_bdev;
> > >   q = bdev_get_queue(bdev);
> > > 
> > > (NULL pointer dereferences apart).
> > 
> > Problem is, there is no general 1:1 mapping between bdev and disks.
> > For the single disk multpile partitions (sda1, sda2...) case, the
> > above scheme is fine and makes the throttle happen at sda granularity.
> > 
> > However for md/dm etc. there is no way (or need?) to reach the exact
> > disk that current blkcg is operating on.
> > 
> > Thanks,
> > Fengguang
> 
> Oh I see, the problem is with stacked block devices. Right, if we set a
> limit for sda and a stacked block device is defined over sda, we'd get
> only the bdev at the top of the stack at balance_dirty_pages() and the
> limits configured for the underlying block devices will be ignored.
> 
> However, maybe for the 90% of the cases this is fine, I can't see a real
> world scenario where we may want to limit only part or indirectly a
> stacked block device...

I agree that throttling will make most sense on the top most device in the 
stack. If we try to do anything on the intermediate device, it might not
make much sense and we will most likely lose context also.

Thanks
Vivek

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2012-03-07 20:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-02  7:18 [ATTEND] [LSF/MM TOPIC] Buffered writes throttling Suresh Jayaraman
2012-03-02 15:33 ` Vivek Goyal
2012-03-05 19:22   ` Fengguang Wu
2012-03-05 21:11     ` Vivek Goyal
2012-03-05 22:30       ` Fengguang Wu
2012-03-05 23:19         ` Andrea Righi
2012-03-05 23:51           ` Fengguang Wu
2012-03-06  0:46             ` Andrea Righi
2012-03-07 20:26               ` Vivek Goyal [this message]
2012-03-05 22:58       ` Andrea Righi
2012-03-07 20:52         ` Vivek Goyal
2012-03-07 22:04           ` Jeff Moyer
2012-03-08  8:08           ` Greg Thelen
2012-03-05 20:23   ` [Lsf-pc] " Jan Kara
2012-03-05 21:41     ` Vivek Goyal
2012-03-07 17:24       ` Jan Kara
2012-03-07 21:29         ` Vivek Goyal
2012-03-05 22:18     ` Vivek Goyal
2012-03-05 22:36       ` Jan Kara
2012-03-07  6:42         ` Fengguang Wu
2012-03-07  6:31     ` Fengguang Wu

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=20120307202616.GJ13430@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=andrea@betterlinux.com \
    --cc=fengguang.wu@intel.com \
    --cc=gthelen@google.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=sjayaraman@suse.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).