This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] use per-cpu variables in cpufreq

To: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
From: Keir Fraser <keir.xen@xxxxxxxxx>
Date: Mon, 30 May 2011 10:45:29 +0100
Cc: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, mark.langsdorf@xxxxxxx
Delivery-date: Mon, 30 May 2011 11:21:41 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=zUS+fn/JnWSM4vSXjG5cnNN4Jd2AMAIG0W2j/4gpKkA=; b=j2LgU8VTPKCMo9b9JM+c0nIudx1H+MGLhsxa78YcPwzALdA2JpN0LeSE+dhFwUmC9y f7p8GHdW3ulCm067wNiomUyDBidPdAAJLHwZYi4EW/XR8pTRNcNrLuVd5ViHe6vII+nz eZm2yX/lyxVleaUF12gtDs22lbzFSqi74UsX4=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=neW74q974SEfJ6F0obJHjzkFCeqyAWca1qTByo+XaRCagDIgfQ0GLF0UPV0e2HF7Hc c9IQKQFYWy+RVXg69f8BAp8tJVdLeiYF6GSIBVdNb1DWqMf1G2QNMkiKYr7KR1zBXFpB m8jxbjahjaKRsicWkZQ++CIHDZIVOYj11NbRs=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4DE32F6A.7030608@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acwerk9F8e7j0dGkgkWeWO/HHFUIHQ==
Thread-topic: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
User-agent: Microsoft-Entourage/
On 30/05/2011 06:47, "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxx> wrote:

>> Specifically, my fear is that this data gets pushed into the hypervisor
>> once-only during dom0 boot (via XENPF_set_processor_pminfo). If it is freed
>> during processor offline, we lose it forever and have no power management
>> when/if a CPU is brought back online. Worse I suspect your patch as it is
>> will crash if some CPUs are offline during boot as you'll deference their
>> per_cpu area which doesn't actually exist unless a CPU is online. You can
>> test this for yourself by adding a maxcpus=1 boot parameter for Xen.
> Indeed.
> Just to understand this completely:
> So when is this info set up for hot-plugged cpus? And what happens if
> a cpu module is removed and later replaced by another module with
> more cores (or threads) than the original one?
> I think the processor pminfo should be set in this case during the hotplug
> handling.

Well, there is a difference between logical and physical cpu hotplug. Xen is
capable of bringing CPUs online and offline without them actually being
physically plugged/unplugged from the mainboard. Indeed our physical hotplug
support is relatively new and I would suspect not much used (and it supports
only physical insertion, not removal!).

Frankly there are a number of questions around CPUs that are physically
plugged in after boot:
 * How does per-CPU ACPI state like PM info get set up?
 * In a system where TSCs are otherwise all perfectly in sync, does the
firmware help us by setting up the new CPUs' TSCs likewise?

I don't actually know the answers to these questions. Maybe dom0 ACPI does
get triggered on physical insertion and knows how to set up PM stuff?

So, when I say CPU hotplug, or online/offline, I'm generally focussing on
logical hotplug only still at the moment. Physical hotplug is a black art
with question marks hanging over it for me. ;-)

 -- Keir

>> The folding of the Intel/AMD structures might still be interesting, and
>> probably belongs as a separate patch anyway.
>> Cc'ing Intel and AMD guys to confirm this.
> Okay, I'm waiting for their opinion.
> Juergen

Xen-devel mailing list