linux-kernel - Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100527005245.1c19675d@lxorguk.ukuu.org.uk>
Date:	Thu, 27 May 2010 00:52:45 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Arve Hjønnevåg <arve@...roid.com>
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

> 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.

That sounds to me like higher level user space implementation plus a
kernel driver imposing a power level limit.

The fact your suspend blockers as a user construct are tied to data isn't
neccessarily what the kernel needs to provide.

That aside we could equally provide latency constraints using a file
handle based semantic like your suspend blockers. That would make it
easier to do suspend blockers in those terms and provide an interface
that can be used for more elegant expression of desire.

I suggested setpidle() to keep resources tied and bounded to tasks and
to make SMP work nicely. I have no problem with the latency constraints
being floating file handles, although some thought would be needed as to
how that is then mapped to SMP.

The problem with an arbitary mapping is that if I have an 8 processor
system I might want to use the latency info to stuff tasks onto different
cores so that most of them are in a deeper idle than the others. I can't
do that unless I know who the latency constraint applies to. But
hopefully someone in scheduler land has bright ideas - eg could we keep a
per task variable and adjust it when people open/close blockers with the
assumption being anyone who has open a given constraint is bound by it
and nobody else is.

Might need it to be a constraintfs so you can open other people's
constraints but all the framework for that is there in the kernel too.

Alan
--
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/