Re: [RFC] writeback and cgroup
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Tejun Heo <tj@xxxxxxxxxx>
- Subject: Re: [RFC] writeback and cgroup
- From: Fengguang Wu <fengguang.wu@xxxxxxxxx>
- Date: Sun, 22 Apr 2012 22:26:48 +0800
- Cc: Vivek Goyal <vgoyal@xxxxxxxxxx>, Jan Kara <jack@xxxxxxx>, Jens Axboe <axboe@xxxxxxxxx>, linux-mm@xxxxxxxxx, sjayaraman@xxxxxxxx, andrea@xxxxxxxxxxxxxxx, jmoyer@xxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, kamezawa.hiroyu@xxxxxxxxxxxxxx, lizefan@xxxxxxxxxx, containers@xxxxxxxxxxxxxxxxxxxxxxxxxx, cgroups@xxxxxxxxxxxxxxx, ctalbott@xxxxxxxxxx, rni@xxxxxxxxxx, lsf@xxxxxxxxxxxxxxxxxxxxxxxxxx
- In-reply-to: <20120420213301.GA29134@google.com>
- User-agent: Mutt/1.5.21 (2010-09-15)
On Fri, Apr 20, 2012 at 02:33:01PM -0700, Tejun Heo wrote:
> On Fri, Apr 20, 2012 at 03:29:30PM -0400, Vivek Goyal wrote:
> > I am personally is not too excited about the case of putting async IO
> > in separate groups due to the reason that async IO of one group will
> > start impacting latencies of sync IO of another group and in practice
> > it might not be desirable. But there are others who have use cases for
> > separate async IO queue. So as long as switch is there to change the
> > behavior, I am not too worried.
>
> Why not just fix cfq so that it prefers groups w/ sync IOs?
There may be a sync+async group in front, but when switch into it, it
decides to give its async queue a run. That's not necessarily a bad
decision, but we do lose some control here.
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Linux ARM Kernel]
[Linux ARM]
[Linux Omap]
[Fedora ARM]
[IETF Annouce]
[Security]
[Bugtraq]
[Linux]
[Linux OMAP]
[Linux MIPS]
[ECOS]
[Tools]
[DDR & Rambus]
[Asterisk Internet PBX]
[Linux API]
[Monitors]