The following patches implement a more generalized infrastructure (than latency.c) for connecting drivers and subsystem's that could implement power performance optimizations with the data needed to implement such policies. These patches are following up on the discussions and presentations at the power management summit last summer. The idea is that from an abstract point of view how much to throttle hardware can be expressed as a function of QoS types of parameters; Latency, throughput, and idle time outs. The qos_parameter patch is intended to put into place the registration and notification infrastructure for enabling QoS based policy choices by drivers, where constraints on throttling are communicated through the qos_params module. Note: it implements a user mode registration protocol where user mode QoS dependents open a misc device node and write there constraints. As long as the file is held open the QoS constraint is included, when the file closes this constraint is removed and a new constraint is computed. I would like some feed back on the idea, implementation and possible applications of this concept we could work on. The current patch set is 2 patches. 1) qos_param : implements the infrastructure and user mode interface 2) no latency : removes latency.c from the kernel tree replacing it with qos_param use. I have a 3rd patch that's a hack application of this qos interface for communicating latency constraints to e1000.c for tweaking the interrupt processing of the e1000 based on acceptable latency gathered from the infrastructure. I'm not proud of this last one but it helps express the idea. Also there is some more documentation and commentary (and an older patch set) on http://www.lesswatts.org/projects/power-qos/ thanks, --mgross _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
