[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4BFFD32B.5090105@nokia.com>
Date: Fri, 28 May 2010 17:28:59 +0300
From: Igor Stoppa <igor.stoppa@...ia.com>
To: ext Alan Cox <alan@...rguk.ukuu.org.uk>
CC: Matthew Garrett <mjg59@...f.ucam.org>,
"tytso@....edu" <tytso@....edu>,
Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>,
Florian Mickler <florian@...kler.org>,
Linux PM <linux-pm@...ts.linux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
"Balbi Felipe (Nokia-D/Helsinki)" <felipe.balbi@...ia.com>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
ext Alan Cox wrote:
> Be that as it may the question of how you manage a naughty app is a good
> one. Historically we've managed them for network abuse, memory abuse, cpu
> use abuse, access rights, but not yet power.
>
> Whether that looks like
>
> setrlimit(pid, LIMIT_CHARGE, 150mWH);
>
> or
> setrlimit(pid, LIMIT_POWER, 150mW);
>
> or something else is the question.
Either way, this will require a detailed model of the system in terms of
latency, throughput, current consumption and heat generation.
Which can be provided only by the HW manufacturer.
But, should such model be available (and we have some form of it for the
OMAP3 in N900), then it can be abstracted through generic interfaces,
which accept constraints and produce the selected target state
(typically a vector of states for each sub component).
igor
--
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