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: Keir Fraser <keir@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Date: Mon, 30 May 2011 07:47:22 +0200
Cc: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, mark.langsdorf@xxxxxxx
Delivery-date: Mon, 30 May 2011 01:39:38 -0700
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=juergen.gross@xxxxxxxxxxxxxx; q=dns/txt; s=s1536b; t=1306744242; x=1338280242; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0dh/r3h/RbvubBCIYsL4b7AqBvZYwcPP+2lLywkdii8=; b=G7OakzAUUqvaj01Hkf34kKDD+dr1V/e8reL7ls5QE4XVlrIX1i0X2au3 590Ay0xRS4iSoUMPGdI50LSGJbdADP9qDmN5SaQu+MdRsxuA9p10H2PaE +0IC/TGGbnAzmJdclqC0rTnIZYafnf4RKpFv6P+NnVgOKINcvhyPU3Ejy WbFffjyR8MRCWu5JKKf8Oq5IzXBYuavBBsDHkjz1HecJl9pS6EZVH3fnU +Kil73VRnze6qo9qaJCi3aQ/NcT1Q;
Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=uHiFr37L1vrnq2D4DB5CzJPUm88T5E2haits6z+lvfWvnJHf4NP/3vAi I6RXOrh07BXgqo1o0RUEsAH1mKFdTm5hQ/+sNGB0ekRLAPo1urqqm/yCn 160TFFKHkBT7+8UNNRg6UyifVtR9tCPLR6UtHg5Tj4FMpR2NwZm18pJ8L uai9kck6RgMwPbU1wilmPbDEBmMXhElszXac5XuvwGcg72en2/v0hxauE Cc36YJG3pvYl/c2IYFRavZXpzacU4;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CA066861.2E032%keir@xxxxxxx>
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>
Organization: Fujitsu Technology Solutions
References: <CA066861.2E032%keir@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110402 Iceowl/1.0b2 Icedove/3.1.9
On 05/28/11 09:52, Keir Fraser wrote:
On 27/05/2011 14:29, "Juergen Gross"<juergen.gross@xxxxxxxxxxxxxx>  wrote:

On 05/27/11 15:11, Keir Fraser wrote:
On 27/05/2011 12:11, "Juergen Gross"<juergen.gross@xxxxxxxxxxxxxx>   wrote:

The cpufreq driver used some local arrays indexed by cpu number. This patch
replaces those arrays by per-cpu variables. The AMD and INTEL specific parts
used different per-cpu data structures with nearly identical semantics.
Fold the two structures into one by adding a generic architecture data item.
Xen's per-cpu data gets freed across cpu offline/online, whereas cpu-indexed
arrays of course do not. Will the cpufreq state be correctly handled across
offline/online if we switch to per-cpu vars?
As far as I could see, yes. The data should only be used for cpus with
a valid acpid->cpuid translation, which is created when a cpu is going
online and destroyed when it is going offline again.
That simply isn't true. acpiid_to_apicid[] is populated during boot and
entries are never destroyed.

Hmm, checked it again and saw you are right. Don't know where I've
been  fooled.

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.


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

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 Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@xxxxxxxxxxxxxx
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

Xen-devel mailing list