linux-kernel - Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.

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: <alpine.LFD.2.00.0908122036580.22946@localhost.localdomain>
Date:	Wed, 12 Aug 2009 20:45:18 -0400 (EDT)
From:	Len Brown <lenb@...nel.org>
To:	Dipankar Sarma <dipankar@...ibm.com>
Cc:	Pavel Machek <pavel@....cz>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	"Li, Shaohua" <shaohua.li@...el.com>,
	Gautham R Shenoy <ego@...ibm.com>,
	Joel Schopp <jschopp@...tin.ibm.com>,
	"Brown, Len" <len.brown@...el.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Balbir Singh <balbir@...ibm.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Ingo Molnar <mingo@...e.hu>,
	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
	"Darrick J. Wong" <djwong@...ibm.com>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.

On Thu, 13 Aug 2009, Dipankar Sarma wrote:

> On Wed, Aug 12, 2009 at 01:58:06PM +0200, Pavel Machek wrote:
> > Hi!
> > 
> > > May be having (to pick a number) 3 possible offline states for all
> > > platforms with one for halt equivalent and one for deepest possible that
> > > CPU can handle and one for deepest possible that platform likes for
> > > C-states may make sense. Will keeps things simpler in terms of usage
> > > expectations and possibly reduce the misuse oppurtubity?
> > 
> > Maybe just going to the deepest offline state automatically is the
> > easiest option?

I agree with Pavel and PeterZ on this.

> In a native system, I think we should the platform-specific code
> export what makes sense. That may be just the lowest possible
> state only. Or may be more than one.

For x86, it is 1 state.

> In a virtualized system, we would want to do at least the following -

Are you talking about Linux as a para-virtualized guest here?

> 1. An offline configuration state where the hypervisor can
> take the cpu back and allocate it to another VM.

The hypervisor gets control no matter what idle state
the guest enters, yes?

> 2. A low-power state where the guest indicates it doesn't need the
> CPU (and can be put in low power state) but doesn't want to give up 
> its allocated cpu share. IOW, no visible configuration changes.
> 
> So, in any case we would probably want more than one states.

How are #1 and #2 different when the hypervisor
gets control in all idle states?  I assert that
they are the same, and thus 1 state will suffice.

> > cpu hotplug/unplug should be rare-enough operation that the latencies
> > do not really matter, right?
> 
> As of now, from the platform perspective, I don't think low-power
> state latencies matter in this code path.

Yay, something we all agree on.

> The only thing that might
> have any relevance is electrical power-off technology and whether
> there may be any h/w specific issues restricting its use.
> I don't know that there will be any, but it may not be a good idea to prevent
> platforms from requiring the use of multiple "offline" states.

Can you give an example of such restrictions? (I can't)

I do not advocate integrating features into the kernel
if they can not be tested and it is uncear that they are needed.
Keep it simple.  Add complexity only when it is clear that you must.

thanks,
Len Brown, Intel Open Source Technology Center.
--
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/