Messages in this thread | | | Date | Thu, 26 Feb 2009 16:11:36 +0800 | From | Li Zefan <> | Subject | Re: [RFC PATCH 1/2] New cgroup subsystem API (->initialize()) |
| |
Bharata B Rao wrote: > On Thu, Feb 26, 2009 at 10:55:54AM +0800, Li Zefan wrote: >> Bharata B Rao wrote: >>> From: Balaji Rao <balajirrao@gmail.com> >>> >>> cgroup: Add ->initialize() to cgroup_subsys structure >>> >>> Some cgroup subsystems (like cpu controller) would need subsystem >>> specific initialization. Such subsystems can define ->initialize() >>> which gets called during cgroup_init() (and not cgroup_init_early()). >>> >> I think it's better to avoid adding this. >> >> It would be best if we can add a hook to initialize init_task_group.stat where >> kmalloc is available but acount_xxx_time() hasn't been called. Otherwise, we >> have to check (tg->stat == NULL) in account_task_group_time(), then why not add >> a hook in smp_init_smp() to do initialization? > > account_xxx_time() is called from scheduler ticks and AFAICS they end up > getting called much before kmalloc is available. In any case, I would think > any hook to just initialize stats for init_task_group would be > very very (cpu controller) subsytem specific. Isn't that bad ? >
Since it's very very cpu subsystem specific, so it's better to use it's own hook. (and because the initialize() API is not so elegant..)
> Another solution I see which can prevent all this is not to collect > stats for init_task_group at all with the understanding that system wide
This came to my mind too. ;)
> stime/utime accounting (which is already present) is essentially the > accounting for init_task_group because init_task_group comprises of all > the tasks in the system. But this would necessiate us to make collection > of cpu controller stats hierarchial. This was one of the questions I asked > in my 0/2 thread. Shouldn't we be doing hierarchial accounting for > cpu controller ? >
Don't know. I have no strong opinion about this. I'm a bit doubt how useful this is.
> Another thing that could be done is to enhance already existing > cpuacct controller to do stime/utime accouting also. cpuacct controller > exists precisely for doing per-cgroup accounting and is there any reason > why these stats shouldn't be part of cpuacct controller. If we do this, > users would be forced to use cpu controller and cpuacct controller > together. Is that a problem ? >
I wondered why these stats is part of cpu subsystem but not cpuacct. And I don't see any problem to use these 2 subsystems together. Actually this is one of the advantage of cgroup.
| |