Re: [Xen-devel] High CPU temp, suspend problem - xen 4.1.5-pre, linux 3.7.x

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.04.13 at 14:09, Ben Guthro <ben@xxxxxxxxxx> wrote:
> On Tue, Apr 16, 2013 at 7:57 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 16.04.13 at 13:49, Ben Guthro <ben@xxxxxxxxxx> wrote:
>>> On Tue, Apr 16, 2013 at 4:47 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>>> On 16.04.13 at 00:09, Marek Marczykowski 
>>>>>>> <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
>>> wrote:
>>>>> II. Not (fully) fixed issues:
>>>>>
>>>>> 1. CPU Pool-0 contains only CPU0 after resume - patch quoted above fixes 
>>>>> the
>>>>> issue, but it isn't applied to xen-unstable
>>>>> 2. After resume scheduler chooses (almost) only CPU0 (above quoted 
>>>>> listing).
>>>>> Removing and re-adding all CPUs to Pool-0 solves the problem. Perhaps some
>>>>> timers are not restarted after resume?
>>>>
>>>> So I understand there is a patch dealing with this, but I'm not clear
>>>> whether that's known to break CPU pools?
>>>
>>> All cpus will end up in cpu pool 0 after S3.
>>> I'm not sure that is "broken" - but it probably isn't ideal either.
>>>
>>> IMO - it is better than the alternative state...but Juergen seems to
>>> disagree.
>>
>> But it can't be that difficult to save/restore pool association on top
>> of said patch?
> 
> I took a brief look, in the hopes of taking a similar tack as with the
> vcpu affinity restoration.
> However, it seems to be a slightly more difficult problem.
> In the vcpu affinity, there was an existing structure to stash away
> the information we needed after resume.
> 
> In a pcpu, there is no such associated metadata...the SMP processor id
> is just an integer.
> So - where would we store the pool information temporarily across the
> S3 process?

Do it the other way around - the CPU pools have a mask of valid
CPUs. You could latch those pre-suspend for each of the pools (e.g.
by again introducing a second mask hanging off the same structure).

(Also adding Juergen to Cc in case he has other thoughts.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel