On Sat, 29 May 2010, Alan Stern wrote:
> On Sat, 29 May 2010, Arve Hjønnevåg wrote:
> > > for (;;) {
> > > while (any IPC requests remain)
> > > handle them;
> > > if (any processes need to prevent suspend)
> > > sleep;
> > > else
> > > write "qos" to /sys/power/state;
> > > }
> > >
> > > The idea is that receipt of a new IPC request will cause a signal to be
> > > sent, interrupting the sleep or the "qos" write.
> >
> > What happen if the signal is right before (or even right after)
> > calling write "qos". How does the signal handler stop the write?
>
> You're right, this is a serious problem. The process would have to
> give the kernel a signal mask to be used during the wait, as in ppoll
> or pselect. There ought to be a way to do this or something
> equivalent.
Okay, here's a possible solution:
char arg[20];
signal_handler()
{
arg[0] = 0;
}
In the main loop:
...
mask signals;
if (we decide to start a QoS-based suspend) {
strcpy(arg, "qos");
unmask signals;
write arg to /sys/power/state;
}
It's hacky but I think it will work.
A more straightforward approach is to give processes the ability to
register their own QoS constraints. This could be done via a custom
driver as Brian suggested or by adding a new system call as Alan Cox
suggested. Then the power manager could be split into two threads, one
of which handles IPC requests and manages QoS constraints, while the
other repeatedly attempts to initiate QoS-based suspends.
Alan Stern
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
