[lkml]   [2007]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] Cpu-hotplug: Using the Process Freezer (try2)
    On Mon, Apr 02, 2007 at 08:16:12AM +0200, Ingo Molnar wrote:
    > * Gautham R Shenoy <> wrote:
    > > Hello Everybody,
    > >
    > > This is another attempt towards process-freezer based cpu-hotplug.
    > > This patchset covers just about everything that was discussed on the
    > > LKML with respect to the freezer-based cpu-hotplug.
    > wow - you have made really nice progress!

    The discussions on the list helped clear up a lot of issues.

    > > I believe that the reasons for freezer failing as N increases are :
    > > - 'make -jN' keeps forking new tasks every now and then, thereby resulting
    > > in a never-ending catching up game in the do_while loop inside
    > > try_to_freeze_tasks (kernel/power/process.c)
    > hm, shouldnt the make be frozen immediately?
    > doesnt the 'please freeze ASAP' flag get propagated to all tasks,
    > immediately? After that point any cloning activity should duplicate that
    > flag too, resulting in any new child freezing immediately too.
    > > Instead of waiting for all the tasks to call try_to_freeze in the
    > > above mentioned do_while loop, I wonder if we can put some hooks in
    > > sched.c so asto not schedule the task marked PF_FREEZING/PF_FROZEN.
    > we could definitely do that - but i think it should be unnecessary: if
    > we mark all tasks as PF_FREEZING atomically, that should result in
    > _every_ task immediately dropping dead (once they get back from
    > TASK_UNINTERRUPTIBLE). No excuses. If there's some longer delay then
    > that can only be explained by some new cloned task/thread slipping
    > through the net somehow. (i.e. the PF_FREEZING flag not being duplicated
    > across fork?)

    I will try again Vatsa's suggestion of having a

    if (freezing(current))

    in copy processes() and check if we can do away with the fork race.
    That sounds lot simpler than the scheduler hooks.

    > i'm wondering about how TASK_UNINTERRUPTIBLE tasks are handled by the
    > freezer: are they assumed frozen immediately, or do we wait until they
    > notice their PF_FREEZING and go into try_to_freeze()? I'd expect
    > TASK_UNINTERRUPTIBLE to be the largest source of latency. (and hence be
    > the primary source for freezing 'failures')

    From what I can make out, we fail to freeze if we have some task in
    the TASK_UNINTERRUPTIBLE state for more than the timeout period.

    The kernel threads have to call try_to_freeze() explicitly and for the
    userspace tasks, try_to_freeze() is called in get_signal_to_deliver().
    The system is considered frozen only when *all* the freezeable tasks
    call try_to_freeze() one way or the other. This is unlikely in case of

    Question is can we have some task in TASK_UNINTERRUPTIBLE state for such
    a long duration (20sec) ??

    > Ingo

    Thanks and Regards
    Gautham R Shenoy
    Linux Technology Center
    IBM India.
    "Freedom comes with a price tag of responsibility, which is still a bargain,
    because Freedom is priceless!"
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-04-02 13:23    [W:0.024 / U:0.200 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site