* PM QoS: Interface design question
@ 2011-02-22 6:30 Simon Horman
2011-02-23 6:47 ` mark gross
0 siblings, 1 reply; 2+ messages in thread
From: Simon Horman @ 2011-02-22 6:30 UTC (permalink / raw)
To: linux-pm; +Cc: Mark Gross
Hi,
I am curious about an aspect of the design of PM QoS.
While working with the devices provided to configure PM QoS it struck me
that this is a rather unusual interface - holding a file descriptor to a
device open so long as configuration parameters apply. I understand that
this is a mechanism to apply parameters on a per-task basis. But I am
wondering if any consideration was given to using cgroups, which seem to me
to be designed specifically for applying QoS parameters on a per-task
basis.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: PM QoS: Interface design question
2011-02-22 6:30 PM QoS: Interface design question Simon Horman
@ 2011-02-23 6:47 ` mark gross
0 siblings, 0 replies; 2+ messages in thread
From: mark gross @ 2011-02-23 6:47 UTC (permalink / raw)
To: Simon Horman; +Cc: linux-pm, Mark Gross
On Tue, Feb 22, 2011 at 03:30:10PM +0900, Simon Horman wrote:
> Hi,
>
> I am curious about an aspect of the design of PM QoS.
>
> While working with the devices provided to configure PM QoS it struck me
> that this is a rather unusual interface - holding a file descriptor to a
> device open so long as configuration parameters apply. I understand that
> this is a mechanism to apply parameters on a per-task basis. But I am
> wondering if any consideration was given to using cgroups, which seem to me
> to be designed specifically for applying QoS parameters on a per-task
> basis.
The design was driven by a worry that we cannot trust user mode to
remember to clean up after itself and we needed a way to make sure any
requests made from user mode would be cleaned up when the application
went way for any reason.
I don't think cgroups existed when we first put this in place. At the
time we where trying to figure out how to get applications that cared
the ability to constrain the throttling of the system. The thinking was
that the app knows better than anyone what its latency and throughput
needs are and if it cared it should set them. I was thinking of a
network game or skype type of thing that would request lower-latency
network when its running as a use case.
I still think it should be the burden of the application to request the
resources it needs if it really cares. But, to date I don't think any
application really cares and the API to user mode should have waited for
user mode users requesting it before being implemented. That way the
abi could have had more input before it got away from us.
--mark
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-02-23 6:47 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-22 6:30 PM QoS: Interface design question Simon Horman
2011-02-23 6:47 ` mark gross
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox