On Wed, Apr 04, 2007 at 01:49:01PM +0200, Ingo Molnar wrote:
>
> i suspect a fork-intensive application like kernbench should be close to
> the worst-case already. A more IO-intensive workload would maximize the
> uninterruptible-sleep latencies perhaps?
Ok. I hope the NFS read/write in a tight
* Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 04, 2007 at 12:04:31PM +0200, Ingo Molnar wrote:
> >
> > yeah, i think you are right - and the TASK_UNINTERRUPTIBLE thing is
> > not only quite complex, it also breaks the symmetry of freezer use
> > (sw-suspend obviously cannot freez
On Wed, Apr 04, 2007 at 12:04:31PM +0200, Ingo Molnar wrote:
>
> yeah, i think you are right - and the TASK_UNINTERRUPTIBLE thing is not
> only quite complex, it also breaks the symmetry of freezer use
> (sw-suspend obviously cannot freeze uninterruptible tasks). We should
> watch whether the c
* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> > Rafael has already sent out the fix for that, but for some reason I
> > don't see it in the -mm.
> >
> > With that fix, freezer and hence hotplug succeeds even when I am
> > running a 'make -j' test.
nice!
> Good to know that!
>
> So Ingo/
On Tue, Apr 03, 2007 at 07:45:16PM +0530, Gautham R Shenoy wrote:
> > Should we ignore this for the timebeing and take up later as and when
> > users report problems?
>
> In my case, the problem of freezer failing was due to the vfork freezer race
> in do_fork. The parent task was waiting_for_comp
On Tue, 3 Apr 2007 21:34:28 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > However, the hunk
> >
> > @@ -1393,7 +1394,9 @@ long do_fork(unsigned long clone_flags,
> > tracehook_report_clone_complete(clone_flags, nr, p);
> >
> > if (clone_flags & CLONE_VFORK) {
>
On Tue, Apr 03, 2007 at 06:26:19PM +0530, Srivatsa Vaddagiri wrote:
>
> Besides, how problematic is this in practise (that threads sleep for
> extended durations in TASK_INTERRUPTIBLE state breaking
> freezer/suspend/hotplug)?
>
> Should we ignore this for the timebeing and take up later as and w
On Tuesday, 3 April 2007 14:01, Gautham R Shenoy wrote:
> On Mon, Apr 02, 2007 at 08:16:12AM +0200, Ingo Molnar wrote:
> >
> > 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_FREE
On Tuesday, 3 April 2007 16:15, Gautham R Shenoy wrote:
> On Tue, Apr 03, 2007 at 06:26:19PM +0530, Srivatsa Vaddagiri wrote:
> >
> > Besides, how problematic is this in practise (that threads sleep for
> > extended durations in TASK_INTERRUPTIBLE state breaking
> > freezer/suspend/hotplug)?
> >
On Mon, Apr 02, 2007 at 08:16:12AM +0200, Ingo Molnar wrote:
>
> 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_UNINTERRUPTIB
On Mon, Apr 02, 2007 at 08:16:12AM +0200, Ingo Molnar wrote:
> 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
On Mon, Apr 02, 2007 at 08:56:07PM +0200, Ingo Molnar wrote:
> ok. But the only real problem would be for_each_online_cpu() loops that
> might sleep, correct?
I would shy from saying that "that's the only problem". It could also be
for_each_cpu_mask(some_mask)
do_somethi
On Monday, 2 April 2007 13:27, Ingo Molnar wrote:
>
> * Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
> > 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.
>
> > Question is can we have some task in TASK_UNIN
* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> flush_workqueue() <- One of biggest offenders of lock_cpu_hotplug() to date
> for_each_online_cpu(cpu)
> flush_cpu_workqueue
> TASK_UNINTERRUPTIBLE sleep
>
> If we don't wait for this thread from being fr
Hi!
> 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
They have to wait. We need all tasks frozen _with no locks held_.
On Mon, Apr 02, 2007 at 06:12:00PM +0530, Srivatsa Vaddagiri wrote:
> On Mon, Apr 02, 2007 at 01:18:28PM +0200, Ingo Molnar wrote:
> > > if (freezing(current))
> > > freeze_process(p); /* function exported by freezer */
> >
> > yeah. (is that safe with tasklist_lock held?)
>
> fr
On Mon, Apr 02, 2007 at 01:18:28PM +0200, Ingo Molnar wrote:
> > if (freezing(current))
> > freeze_process(p); /* function exported by freezer */
>
> yeah. (is that safe with tasklist_lock held?)
from my scan of the code, it appears to be safe ..
> i'm wondering whether we c
* Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
> 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.
> Question is can we have some task in TASK_UNINTERRUPTIBLE state for
> such a long duration (20sec) ??
yes, e
On Mon, Apr 02, 2007 at 08:16:12AM +0200, Ingo Molnar wrote:
>
> * Gautham R Shenoy <[EMAIL PROTECTED]> 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 wit
* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 02, 2007 at 08:16:12AM +0200, Ingo Molnar wrote:
> > 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
On Mon, Apr 02, 2007 at 08:16:12AM +0200, Ingo Molnar wrote:
> 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 free
* Gautham R Shenoy <[EMAIL PROTECTED]> 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
22 matches
Mail list logo
