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]
Date:	Thu, 27 May 2010 14:35:56 -0400
From:	Zygo Blaxell <vger-linux-omap-esightcorp@...ltoo.hungrycats.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Arve Hjønnevåg <arve@...roid.com>,
	Florian Mickler <florian@...kler.org>,
	Vitaly Wool <vitalywool@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Paul@...p1.linux-foundation.org, felipe.balbi@...ia.com,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Thu, May 27, 2010 at 05:16:15PM +0100, Alan Cox wrote:
> So you need
> 
> 	Userspace -> QoS guarantee expression, implied resource
> 			expression via device use. *NO* knowledge of
> 			device or platform in the application

I have a pile of use cases where I want to turn off "implied resource
expression via device use."  There are two orthogonal variables to
consider:

1.  I'm drawing cows on the screen (or asking another process to do so
on my behalf).

2.  I care whether anyone can actually see the cows, and I'm willing
(or not) to burn power to make them visible.

Quite often, I'm drawing cows but I don't care about cow visibility,
so I would tell PM to turn the display off when the PM framework is
looking for ways to conserve power; however, if the animated cow is part
of an alarm clock application, then I want the display on, powering it
up if was previously turned off.

A real-world example of this is a backup process on a file server.
I'd like to tell the kernel that the backup process's CPU usage and
disk I/O is *not* implied resource expression, and if there's no other
processes using the CPU or disks, the kernel can just power down the
drives or idle the CPU on a whim.  The backup process can hang until
some other process comes along to wake the drives and CPU up again,
and then the backups will run during the idle time while the drive
is waiting for new requests from other processes.  Obviously if the
backup process is trying to write dirty pages to a powered-down drive
there will be problems (memory starvation and lost data come to mind),
so I'd make sure I don't do that.

I'd also like to change my mind about these sorts of things on the fly,
without requiring hooks in the backup process itself.  I'm thinking
of a syscall with PID, FD, mode bits (read/write?  iowait/runnable?),
and policy (whether usage implies expression).

I can express mostly the same things if "policy" was "maximum latency,"
but not all.  Consider how you'd have to specify latencies to get hard
disks that spin down when idle, spin up immediately if read requests are
issued, but wait several minutes to spin up if write requests are issued.
I can't specify that with a single latency value since it would result
in either unacceptably large latencies in some cases, or the disks
would never spin down.  I'd need a matrix with drive power states as
rows and read/write operations as columns, either per process or per
file descriptor.  Also something in user-space needs to know about the
approximate value for hard disk spin-up times in order to set their PM
QoS constraints high enough to be useful but also low enough to be useful.

Well, maybe the last problem can be resolved by specifying QoS constraints
in bands.  You'd have a QOS_OTHER band that applies to processes that
haven't specified a constraint, and a QOS_EXPLICIT band that applies to
those that have, and you'd be able to change all the QOS_OTHER processes
at once.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ