On Saturday, August 20, 2011, Mark Brown wrote: > On Fri, Aug 19, 2011 at 10:42:20PM +0200, Rafael J. Wysocki wrote: > > > I really wouldn't like the discussion to go in circles. > > > First, please tell me what in particular you are objecting to, > > because I don't think that's any of the patches that have been > > sent to the linux-pm list to date. > > The original issue that Kevin raised and CCed me in on was the idea of > exposing raw per-device wakeup latency constraints to userspace; it > seems much better to expose user level requirements via subsystem > interfaces and let the subsystem and driver translate these into actual > wakeup latency constraints: > > https://lists.linux-foundation.org/pipermail/linux-pm/2011-August/032422.html > https://lists.linux-foundation.org/pipermail/linux-pm/2011-August/032428.html OK, so let's clarify things. I'm not sure what you mean by "exposing per-device wakeup latency constraints to user space". I simply thought it might be useful to allow user space to add and remove those, in analogy to what it can do with the currently available PM QoS constraints. My point is that this won't prevent kernel subsystems from adding their own PM QoS constraints to devices and the constraints added by user space will only have effect if they make the devices stay active for longer times. In consequence, they may only increase the energy usage of the system and shouldn't affect functionality. The reason why I think this may be useful is that I can readily imagine scenarios in which user space (think a distribution or system vendor) will want to do something that hasn't been anticipated by kernel developers and the ability to add per-device PM QoS constraints will allow it to do that without modifying the kernel. Also, it will help to test and debug new drivers and subsystems. I don't want to prevent kernel subsystems from using their own interfaces to acquire user-level input that translates into PM QoS constraints. I simply think it won't _hurt_ to provide user space with an additional level of control over per-device PM QoS constraints. > This is much easier for users as it translates into something they're > actually doing (and in most cases the driver can make it Just Work) and > it means that off the shelf applications will end up tuning the system > appropriately by themselves. The _end_ users really don't care. They'll use whatever settings the user interface exposes to them. Moreover, even if there is an interface for user space to add per-device PM QoS constraints, that doesn't mean the user space is _required_ to use it. If it doesn't, everything will work as you describe. > I'm additionally concerned that if we expose this stuff directly to userspace > that's an open invitation to driver authors to not even bother trying to make > the kernel figure this stuff out by itself and to instead tie the system > together with magic userspace. As I said, I don't think we can prevent that from happening anyway. Worst case people will add strange interfaces to drivers making them incompatible with anything except for their crazy user space. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
