linux-kernel - Re: [RFC/RFT][PATCH v2 0/6] PM / QoS: Introduce latency tolerance device PM QoS type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1603022.bSUdZfxtWV@vostro.rjw.lan>
Date:	Fri, 24 Jan 2014 16:30:28 +0100
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:	Linux PM list <linux-pm@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC/RFT][PATCH v2 0/6] PM / QoS: Introduce latency tolerance device PM QoS type

On Friday, January 24, 2014 04:19:23 PM Mika Westerberg wrote:
> On Thu, Jan 23, 2014 at 02:34:59PM +0100, Rafael J. Wysocki wrote:
> > On Friday, January 17, 2014 03:42:13 PM Rafael J. Wysocki wrote:
> > > Hi All,
> > > 
> > > On some platforms hardware may switch to an energy-saving mode on the fly
> > > on the basis of certain utilization metrics used by it.  That usually is
> > > desirable from the energy conservation standpoint, but it generally causes
> > > latencies to increase which may adversely affect some operations.  For this
> > > reason, the platforms in question usually provide some interfaces for software
> > > to indicate its latency tolerance and possibly to prevent the energy-saving
> > > modes from being selected too aggressively.
> > > 
> > > The following series of patches introduces a device PM QoS type allowing
> > > those interfaces to be used by kernel code and user space.  It is designed
> > > in analogy with the existing resume latency device PM QoS type, which allows
> > > some pieces of the existing device PM QoS code to be re-used and makes the
> > > new user space interface fit into the existing framework.
> > > 
> > > Patch [1/5] modifies the names of symbols, variables, functions and structure
> > > fields associated with the existing resume latency device PM QoS type to
> > > avoid any confusion with the new one introduced by the subsequent patches.
> > > 
> > > Patch [2/5] introduces a new field in struct pm_qos_constraints for specifying
> > > a special value to be returned as the effective requirement when the given list
> > > of PM QoS requirements is empty.  That field is necessary for the new latency
> > > tolerance device PM QoS type.
> > > 
> > > Patch [3/5] introduces the latency tolerance device PM QoS type along with
> > > documentation.
> > > 
> > > Patch [4/5] modifies the ACPI LPSS (Low-Power Subsystem) driver to hook up
> > > LPSS devices to the new latency tolerance device PM QoS interface.
> > > 
> > > Patch [5/5] modifies the dev_pm_qos_add_ancestor_request() routine so that it
> > > can be used by drivers of devices without hardware latency tolerance support
> > > for specifying their requirements via the ancestors of those devies.
> > 
> > As usual, testing uncovered some issues, so an updated series follows.
> 
> I tested this series on HSWULT and adding/removing QoS LTR requests from
> both userspace and from a modified i2c-hid driver (calling
> dev_pm_qos_add_ancestor_request()) and seems to work nicely -- When I read
> back the HW LTR values they are what is expected.
> 
> Tested-by: Mika Westerberg <mika.westerberg@...ux.intel.com>

Great, thanks a lot for doing that!

Rafael

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