Message-ID: <AANLkTilz8z2rWV2gj48FLnIG9UIYA2W-pY_WiTmj6LH1@mail.gmail.com>
Date:	Wed, 26 May 2010 16:00:14 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Brian Swetland <swetland@...gle.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Peter Zijlstra <peterz@...radead.org>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	linux-kernel@...r.kernel.org, Randy Dunlap <rdunlap@...otime.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ryusuke Konishi <konishi.ryusuke@....ntt.co.jp>,
	Jim Collar <jim.collar@...are.net>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Avi Kivity <avi@...hat.com>, Len Brown <len.brown@...el.com>,
	Pavel Machek <pavel@....cz>, Magnus Damm <damm@...l.co.jp>,
	Nigel Cunningham <nigel@...onice.net>,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend 
	blockers from user-space

On Wed, May 26, 2010 at 4:00 PM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> desired.  The device node interface came about after discussions last
>> year and concerns that userspace could create an unbounded number of
>> suspend blockers.
>
> Surely you only need one block per task (or better yet one expression of

No, many suspend blockers protect data, not tasks. We block suspend
when there are unprocessed input events in the kernel queue.
User-space then blocks suspend before reading those events, and it
blocks suspend using a different suspend blocker when its queue of
processed events become not-empty.

> latency per task). If not can you explain why a setup which has a per
> task expression of latency needs (and a 'hard limit' set which you can't
> then bump back down except as root) isn't enough ?
>

> I'd really like this lot to also fix the hard real time and power
> management problem we have today and to try an fix the "suspend is
> special and different" mentality in the kernel, which is getting less and
> less true on a variety of chips.
>
>> > It's all an economic system, proprietary app vendors are in it to make
>> > money, some will therefore game the system and the rest will be forced to
>> > follow to keep their playing field fair.
>>
>> Untrusted (non-system) code can't directly access the device node from
>> userspace in the Android world -- so directly created suspend blockers
>
> Great - but the world is not Android and even if they can't access it
> directly but get passed a handle they can play.
>
>> For suspend blockers created by drivers and by trusted userspace
>> processes, having a meaningful name significantly helps statistics
>> gathering.
>
> By drivers I agree but in the driver case the cost is minimal because
> there should not be many and it is bounded clearly. Again I really think
> 'suspend blocking' is the wrong expression.
>
> A driver needs to express
>
> 'Don't go below this latency'
>
> and
>
> 'Don't go below this state'
>
> This is more generic and helps our power management do the right thing on
> all boxes. For example a serial port can meaningfully say 'I want X
> latency worst case' based upon the fact the fifo is 64 bytes and the user
> space just asked for 115,200 baud.
>
> The don't go below for states out of which the device must wake but
> cannot. Eg if your device is being told by user space to set wake on lan
> and can only wake on lan from a higher state than 'off' it needs to say
> so.
>
> Alan
>



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

Powered by blists - more mailing lists