lkml.org 
[lkml]   [2009]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 1/2] New cgroup subsystem API (->initialize())
    On Thu, Feb 26, 2009 at 04:11:36PM +0800, Li Zefan wrote:
    > 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.

    Ok, so if there are no objections, my next version would move these
    stats to cpuacct subsystem.

    Regards,
    Bharata.


    \
     
     \ /
      Last update: 2009-02-26 11:13    [W:0.030 / U:0.104 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site