lkml.org 
[lkml]   [2011]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 5/6 v4] cfq-iosched: CFQ group hierarchical scheduling and use_hierarchy interface
On Sat, Feb 12, 2011 at 10:21:47AM +0800, Gui Jianfeng wrote:
[..]
> >> +static struct cfq_group *
> >> +cfq_find_alloc_cfqg(struct cfq_data *cfqd, struct cgroup *cgroup, int create)
> >> +{
> >> + struct blkio_cgroup *blkcg = cgroup_to_blkio_cgroup(cgroup);
> >> + struct cfq_group *cfqg = NULL;
> >> + void *key = cfqd;
> >> + struct backing_dev_info *bdi = &cfqd->queue->backing_dev_info;
> >> + unsigned int major, minor;
> >> +
> >> + cfqg = cfqg_of_blkg(blkiocg_lookup_group(blkcg, key));
> >> + if (cfqg && !cfqg->blkg.dev && bdi->dev && dev_name(bdi->dev)) {
> >> + sscanf(dev_name(bdi->dev), "%u:%u", &major, &minor);
> >> + cfqg->blkg.dev = MKDEV(major, minor);
> >> + goto done;
> >> + }
> >
> > Should we make this updation of this info hierarhical?
>
> IMHO, it's fine to defer the updation when we really get the cfqg.

But if cfqg is alrady present, we will never hit the allocation path
again. So if somebody creates 2-3 level deep hierarchy and does IO
only in the children cgroup, parent cgroups will potentially not get
device info updated hence no visible stats?

Thanks
Vivek


\
 
 \ /
  Last update: 2011-02-14 19:07    [W:0.091 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site