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

[Ben Guthro <ben@xxxxxxxxxx>]

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?

Ben

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