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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
