Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

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

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