From: Alan Stern on
On Thu, 6 May 2010, Rafael J. Wysocki wrote:

> > Here's a completely new issue. When using opportunistic suspends on an
> > SMP system, it could happen that the system gets a wakeup event and
> > this routine starts running again before the event's IRQ handler has
> > finished (or has enabled a suspend blocker). The system would
> > re-suspend too soon.
>
> This routine will be run from a freezable workqueue.

But how do you know that processes won't get unfrozen until all the
pending IRQs have been handled? Imagine something like this:

CPU 0 CPU 1
----- -----
Wake up non-boot CPUs
Resume devices Invoke the IRQ handler

[ CPU 0 should wait here for the handler to finish,
but it doesn't ]

Defrost threads Handler running...
Workqueue routine runs
Start another suspend
Handler enables a suspend blocker,
but it's too late

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arve Hjønnevåg on
On Thu, May 6, 2010 at 12:40 PM, Alan Stern <stern(a)rowland.harvard.edu> wrote:
> On Thu, 6 May 2010, Rafael J. Wysocki wrote:
>
>> > Here's a completely new issue. �When using opportunistic suspends on an
>> > SMP system, it could happen that the system gets a wakeup event and
>> > this routine starts running again before the event's IRQ handler has
>> > finished (or has enabled a suspend blocker). �The system would
>> > re-suspend too soon.
>>
>> This routine will be run from a freezable workqueue.
>
> But how do you know that processes won't get unfrozen until all the
> pending IRQs have been handled? �Imagine something like this:
>
> � � � �CPU 0 � � � � � � � � � CPU 1
> � � � �----- � � � � � � � � � -----
> � � � �Wake up non-boot CPUs
> � � � �Resume devices � � � � �Invoke the IRQ handler
>
> � � � �[ CPU 0 should wait here for the handler to finish,
> � � � � �but it doesn't ]
>
> � � � �Defrost threads � � � � Handler running...
> � � � �Workqueue routine runs
> � � � �Start another suspend
> � � � � � � � � � � � � � � � �Handler enables a suspend blocker,
> � � � � � � � � � � � � � � � �but it's too late

It is not optimal, but it is not too late. We check if any suspend
blockers block suspend after disabling non-boot cpus so as long as
this is done in a way that does not lose interrupts the resuspend
attempt will not succeed.

--
Arve Hj�nnev�g
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on
On Thu, 6 May 2010, Arve Hj�nnev�g wrote:

> On Thu, May 6, 2010 at 12:40 PM, Alan Stern <stern(a)rowland.harvard.edu> wrote:
> > On Thu, 6 May 2010, Rafael J. Wysocki wrote:
> >
> >> > Here's a completely new issue. �When using opportunistic suspends on an
> >> > SMP system, it could happen that the system gets a wakeup event and
> >> > this routine starts running again before the event's IRQ handler has
> >> > finished (or has enabled a suspend blocker). �The system would
> >> > re-suspend too soon.
> >>
> >> This routine will be run from a freezable workqueue.
> >
> > But how do you know that processes won't get unfrozen until all the
> > pending IRQs have been handled? �Imagine something like this:
> >
> > � � � �CPU 0 � � � � � � � � � CPU 1
> > � � � �----- � � � � � � � � � -----
> > � � � �Wake up non-boot CPUs
> > � � � �Resume devices � � � � �Invoke the IRQ handler
> >
> > � � � �[ CPU 0 should wait here for the handler to finish,
> > � � � � �but it doesn't ]
> >
> > � � � �Defrost threads � � � � Handler running...
> > � � � �Workqueue routine runs
> > � � � �Start another suspend
> > � � � � � � � � � � � � � � � �Handler enables a suspend blocker,
> > � � � � � � � � � � � � � � � �but it's too late
>
> It is not optimal, but it is not too late. We check if any suspend
> blockers block suspend after disabling non-boot cpus so as long as
> this is done in a way that does not lose interrupts the resuspend
> attempt will not succeed.

Is it possible for the resuspend to disable CPU 1 before the IRQ
handler can enable its suspend blocker? (Probably not -- but I don't
know enough about how non-boot CPUs are enabled or disabled.)

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on
On Thu 2010-05-13 21:11:06, Arve Hj??nnev??g wrote:
> Adds /sys/power/policy that selects the behaviour of /sys/power/state.
> After setting the policy to opportunistic, writes to /sys/power/state
> become non-blocking requests that specify which suspend state to
> enter

Yeah, one file selects behavior of another file, and to read available
states for opportunistic, you have to write to file first.

I still don't like the interface.

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on
Hello,

(sorry about late reply)

On 04/30/2010 07:26 PM, Oleg Nesterov wrote:
> Currently _cpu_down() can't flush and/or stop the frozen cwq->thread.
>
> IIRC this is fixable, but needs the nasty complications. We should
> thaw + stop the frozen cwq->thread, then move the pending works to
> another CPU.

Oh, this isn't an issue w/ cmwq. While frozen all new works are
collected into per-cpu delayed worklist and while frozen trustee in
charge of the cpu will keep waiting. Once thawed, trustee will
execute all works including the delayed ones unbound to any cpu.

Thanks.

--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/