[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.