Date: Wed, 26 Sep 2007 15:37:12 -0700
From: Mark Gross <mgross@linux.intel.com>
To: linux-pm <linux-pm@lists.linux-foundation.org>,
       lkml <linux-kernel@vger.kernel.org>
Cc: mgross@linux.intel.com
Subject: [RFC] QoS power Management enabling patch set
Message-ID: <20070926223712.GA22029@linux.intel.com>
Reply-To: mgross@linux.intel.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.11
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2036
Lines: 49

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/