Re: [PATCH 4/6] xen: don't free percpu areas during suspend

From: "Jan Beulich" <JBeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Juergen Gross <jgross@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH 4/6] xen: don't free percpu areas during suspend
Date: Thu, 11 Apr 2019 03:49:15 -0600	[thread overview]
Message-ID: <5CAF0D9B0200007800226882@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <5C9C7FD202000078002225AB@prv1-mh.provo.novell.com>

>>> On 28.03.19 at 09:03, <JBeulich@suse.com> wrote:
> For core parking I wonder whether core_parking_helper()
> shouldn't, first of all, invoke cpu_{up,down}_helper(). This
> wouldn't be enough, though - the policy hooks need to honor
> opt_smt as well.

Actually no, there was no problem at the time there: With
opt_smt set to false, no secondary thread would ever have
made it into core_parking_cpunum[] (that's where CPU numbers
to be passed to cpu_up() get taken from). A problem here was
introduced only by Andrew's 2bed1bc241, making it possible for
opt_smt to change at runtime. I think I'll make a patch to have
smt_up_down_helper() call into core-parking code to purge
CPUs from core_parking_cpunum[] as needed.

The interaction of core-parking and xen-hptool activities is up
for discussion anyway, I think. At least to me it's not
immediately clear which of the two should take priority.
Allowing admins to shoot themselves in the foot (as we appear
to do now) is a reasonable possibility, but not the only one, the
more that the platform is liable to notice higher power
consumption and to subsequently request offlining of CPUs
again anyway.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel