lkml.org 
[lkml]   [2011]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/1, v6] cgroup/freezer: add per freezer duty ratio control
    On Thu, Feb 10, 2011 at 11:15:22AM +0200, Kirill A. Shutemov wrote:
    > On Wed, Feb 09, 2011 at 07:04:42PM -0800, Matt Helsley wrote:
    > > > +{
    > > > + struct cgroup *cgroup = (struct cgroup *)data;
    > > > + struct freezer *freezer = cgroup_freezer(cgroup);
    > > > +
    > > > + do {
    > > > + if (freezer->duty.ratio < 100 && freezer->duty.ratio > 0 &&
    > > > + freezer->duty.period_pct_ms) {
    > > > + if (try_to_freeze_cgroup(cgroup, freezer))
    > > > + pr_info("cannot freeze\n");
    > > > + msleep(freezer->duty.period_pct_ms *
    > > > + freezer->duty.ratio);
    > > > + unfreeze_cgroup(cgroup, freezer);
    > > > + msleep(freezer->duty.period_pct_ms *
    > > > + (100 - freezer->duty.ratio));
    > > > + } else {
    > > > + sleep_on(&freezer_wait);
    > > > + pr_debug("freezer thread wake up\n");
    > > > + }
    > > > + } while (!kthread_should_stop());
    > > > + return 0;
    > > > +}
    > >
    > > Seems to me you could avoid the thread-per-cgroup overhead and the
    > > sleep-loop code by using one timer-per-cgroup. When the timer expires
    > > you freeze/thaw the cgroup associated with the timer, setup the next
    > > wakeup timer, and use only one kernel thread to do it all. If you
    > > use workqueues you might even avoid the single kernel thread.
    > >
    > > Seems to me like that'd be a good fit for embedded devices.
    >
    > I proposed to use delayed workqueues (schedule_delayed_work()).

    Even better.

    >
    > > > +#define FREEZER_KH_PREFIX "freezer_"
    > > > +static int freezer_write_param(struct cgroup *cgroup, struct cftype *cft,
    > > > + u64 val)
    > > > +{
    > > > + struct freezer *freezer;
    > > > + char thread_name[32];
    > > > + int ret = 0;
    > > > +
    > > > + freezer = cgroup_freezer(cgroup);
    > > > +
    > > > + if (!cgroup_lock_live_group(cgroup))
    > > > + return -ENODEV;
    > > > +
    > > > + switch (cft->private) {
    > > > + case FREEZER_DUTY_RATIO:
    > > > + if (val >= 100 || val < 0) {
    > > > + ret = -EINVAL;
    > > > + goto exit;
    > > > + }
    > > > + freezer->duty.ratio = val;
    > >
    > > Why can't val == 100? At that point it's always THAWED and no kernel
    > > thread is necessary (just like at 0 it's always FROZEN and no kernel
    > > thread is necessary).
    >
    > val == 100 is interface abuse, I think. I just turn off the feature, if
    > you want.

    And how is userspace supposed to do that at runtime if we can't disable
    it by writing to the state file (see below)? Then I don't see anyway
    to get rid of the duty cycling unless you clear out the cgroup and
    recreate it.

    Frankly, I think 0 and 100 percent aren't interface abuse. Anybody
    who knows it's a percent value will naturally try to put 0 or 100
    there.

    > > > static struct cftype files[] = {
    > > > {
    > > > .name = "state",
    > > > .read_seq_string = freezer_read,
    > > > .write_string = freezer_write,
    > >
    > > It's not clear what should happen when userspace writes the state
    > > file after writing a duty_ratio_pct.
    >
    > It should return -EBUSY, I think.

    Ahh, that is another solution I hadn't considered. That further proves my
    point though :). It's not obvious what should happen and that's a red-flag
    that we're defining policy and should be careful which solution we select.

    >
    > > > },
    > > > + {
    > > > + .name = "duty_ratio_pct",
    > > > + .private = FREEZER_DUTY_RATIO,
    > > > + .read_u64 = freezer_read_duty_ratio,
    > > > + .write_u64 = freezer_write_param,
    > > > + },
    > >
    > > nit: Why use a u64 for a value that can only be 0-100? (or perhaps
    > > 0-1000 if you wanted sub-1% granularity...)
    >
    > .read_u64/.write_64 is a standard cgroup's interface.

    Oops -- I was thinking there was a smaller variant of these.

    Cheers,
    -Matt Helsley


    \
     
     \ /
      Last update: 2011-02-10 20:03    [W:0.029 / U:31.028 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site