Re: [PATCH 11/11] blkcg: implement per-blkg request allocation

[Vivek Goyal <vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On Fri, Apr 27, 2012 at 08:45:02AM -0700, Tejun Heo wrote:
> On Fri, Apr 27, 2012 at 11:40:34AM -0400, Vivek Goyal wrote:
> > On Fri, Apr 27, 2012 at 08:02:17AM -0700, Tejun Heo wrote:
> > > Hello,
> > > 
> > > On Fri, Apr 27, 2012 at 10:54:01AM -0400, Jeff Moyer wrote:
> > > > > This patch implements per-blkg request_list.  Each blkg has its own
> > > > > request_list and any IO allocates its request from the matching blkg
> > > > > making blkcgs completely isolated in terms of request allocation.
> > > > 
> > > > So, nr_requests is now actually nr_requests * # of blk cgroups.  Is that
> > > > right?  Are you at all concerned about the amount of memory that can be
> > > > tied up as the number of cgroups increases?
> > > 
> > > Yeah, I thought about it and I don't think there's a single good
> > > solution here.  The other extreme would be splitting nr_requests by
> > > the number of cgroups but that seems even worse - each cgroup should
> > > be able to hit maximum throughput.  Given that a lot of workloads tend
> > > to regulate themselves before hitting nr_requests, I think it's best
> > > to leave it as-is and treat each cgroup as having separate channel for
> > > now.  It's a configurable parameter after all.
> > 
> > So on a slow device a malicious application can easily create thousands
> > of group, queue up tons of IO and create unreclaimable memory easily?
> > Sounds little scary. 
> 
> Malicious application may just jack up nr_requests.

Not an unpriviliged malicious application. In typical cgroup scenario, we
can allow unpriviliged users to create child cgroups so that it can
further subdivide its resources to its children group. (ex. put firefox
in one cgroup, open office in another group etc.).

So it is not same as jack up nr_requests.

Thanks
Vivek