linux-kernel - Re: [RFC PATCH V4 5/5] cpuidle: cpuidle driver for apm

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: <20110324162131.GA16408@dirshya.in.ibm.com>
Date:	Thu, 24 Mar 2011 21:51:31 +0530
From:	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>
To:	Trinabh Gupta <trinabh@...ux.vnet.ibm.com>
Cc:	Len Brown <lenb@...nel.org>, arjan@...ux.intel.com,
	Stephen Rothwell <sfr@...b.auug.org.au>, peterz@...radead.org,
	suresh.b.siddha@...el.com, benh@...nel.crashing.org,
	venki@...gle.com, ak@...ux.intel.com, linux-kernel@...r.kernel.org,
	xen-devel@...ts.xensource.com
Subject: Re: [RFC PATCH V4 5/5] cpuidle: cpuidle driver for apm

* Trinabh Gupta <trinabh@...ux.vnet.ibm.com> [2011-03-24 19:58:29]:

> 
> 
> On 03/24/2011 02:02 AM, Len Brown wrote:
> >>>Also wondering why you would ever have a different idle routine on
> >>>different cpus?
> >>
> >>Yes, this is an ongoing debate. Apparently it is a possibility
> >>because of ACPI bugs. CPU's can have asymmetric C-states
> >>and overall different idle routines on different cpus. Please
> >>refer to http://lkml.org/lkml/2009/9/24/132 and
> >>https://lkml.org/lkml/2011/2/10/37 for a discussion around this.
> >
> >Althought the ACPI specification allows the BIOS to tell the OS
> >about different C-states per-processor, I know of zero system
> >in the field and zero systems in development that require that
> >capability.  That isn't a guarantee that capability will never
> >be used, but I'm not holding my breath.
> >
> >If there are systems with broken tables that make them
> >appear asymetric, then we should have a workaround that handles
> >that case, rather than complicating the normal code for
> >the broken case.
> >
> >So I recommend deleting the extra per-cpu registration stuff
> >unless there is some other architecture that requires it
> >and can't hadle the asymmetry in another way.

Hi Len,

The fear of breaking legacy hardware is what is holding us.  Arjan
also pointed that there are systems that has asymmetric C-States
either intentionally or due to a bug.  I agree with you that we should
remove per-cpu registration at this point and move forward with
a single registration.  We can workaround the corner cases.

> Yes, lets go forward with removal of per-cpu registration
> and handle rare case of asymmetry in some other may.

Yes.  Lets discuss the design/problems on the other patch series.
(http://lkml.org/lkml/2011/3/22/161)

> Using intersection or union of C-states for each cpu may
> be a solution. Using intersection or lowest common C-state
> has the corner case that we could have packages/cores
> supporting a new lower C-state in case of thermal limit and
> they would want OS to go to this state. Using intersection
> or lowest common C-state may prevent this.
> 
> Another option is to use union of C-states;
> but I am not sure what happens if a CPU uses a state that
> is not reported for it???
> 
> Maybe there is some other way to handle asymmetry ??

The simplest method will be a union of all C-States.  Basically let
the CPU that reports the maximum C-States to register or override the
current setup.  During boot-up allow the first CPU to do the
registration, but later override if another CPU comes up with more
C-States.

This will work assuming that calling a new (deeper) C-State on CPUs
that did not report them will cause no harm.  It should degenerate to
closest supported C-State.

> >
> >>I have posted a patch series that does global registration
> >>i.e same idle routines for each cpu. Please check
> >>http://lkml.org/lkml/2011/3/22/161 . That series applies on
> >>top of this series. Global registration significantly
> >>simplifies the design, but still we are not sure about the
> >>direction to take.
> >
> >I'll review that.
> Thanks; please review especially the data structure changes
> https://lkml.org/lkml/2011/3/22/162

Single registration will allow us to combine struct cpuidle_device and
struct cpuidle_driver, and simplify the framework for large systems.
AFAIK other archs like powerpc or ARM would not need per-cpu
definitions.

--Vaidy

--
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/