Re: [ATTEND] [LSF/MM TOPIC] Buffered writes throttling

[Andrea Righi <andrea@betterlinux.com>]

On Mon, Mar 05, 2012 at 03:51:32PM -0800, Fengguang Wu wrote:
> On Tue, Mar 06, 2012 at 12:19:30AM +0100, Andrea Righi wrote:
> > On Mon, Mar 05, 2012 at 02:30:29PM -0800, Fengguang Wu wrote:
> > > On Mon, Mar 05, 2012 at 04:11:15PM -0500, Vivek Goyal wrote:
> > ...
> > > > But looks like we don't much choice. As buffered writes can be controlled
> > > > at two levels, we probably need two knobs. Also controlling writes while
> > > > entring cache limits will be global and not per device (unlinke currnet
> > > > per device limit in blkio controller). Having separate control for "dirty
> > > > rate limit" leaves the scope for implementing write control at device
> > > > level in the future (As some people prefer that). In possibly two 
> > > > solutions can co-exist in future.
> > > 
> > > 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...

Thanks,
-Andrea

--
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>