From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: Stephan Diestelhorst <stephan.diestelhorst@amd.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
"Przywara, Andre" <Andre.Przywara@amd.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Keir Fraser <keir@xen.org>,
Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: Hypervisor crash(!) on xl cpupool-numa-split
Date: Thu, 03 Feb 2011 06:57:11 +0100 [thread overview]
Message-ID: <4D4A43B7.5040707@ts.fujitsu.com> (raw)
In-Reply-To: <201102021701.05665.stephan.diestelhorst@amd.com>
On 02/02/11 17:01, Stephan Diestelhorst wrote:
> On Wednesday 02 February 2011 16:14:25 Juergen Gross wrote:
>> On 02/02/11 15:39, Stephan Diestelhorst wrote:
>>> We have the following theory of what happens:
>>> * some vcpus of a particular domain are currently in the process of
>>> being moved to the new pool
>>
>> The only _vcpus_ to be moved between pools are the idle vcpus. And those
>> never contribute to accounting in credit scheduler.
>>
>> We are moving _pcpus_ only (well, moving a domain between pools actually
>> moves vcpus as well, but then the domain is paused).
>
> How do you ensure that the domain is paused and stays that way? Pausing
> the domain was what I had in mind, too...
Look at sched_move_domain() in schedule.c: I'm calling domain_pause()
before moving the vcpus and domain_unpause() after that.
>
>>> Despite the rant, it is amazing to see the ability to move running
>>> things around through this remote continuation trick! In my (ancient)
>>> balancer experiments I added hypervisor-threads just for side-
>>> stepping this issue..
>>
>> I think the easiest way to solve the problem would be to move the cpu to the
>> new pool in a tasklet. This is possible now, because tasklets are always
>> executed in the idle vcpus.
>
> Yep. That was exactly what I build. At the time stuff like that did
> not exist (2005).
>
>> OTOH I'd like to understand what is wrong with my current approach...
>
> Nothing, in fact I like it. In my rant I complained about the fact
> that splitting the critical section accross this continuation looks
> scary, basically causing some generic red lights to turn on :-) And
> making reasoning about the correctness a little complicated, but that
> may well be a local issue ;-)
Perhaps you can help solving the miracle:
Could you replace the BUG_ON in sched_credit.c:389 with something like this:
if (!is_idle_vcpu(per_cpu(schedule_data, cpu).curr)) {
extern void dump_runq(unsigned char key);
struct vcpu *vc = per_cpu(schedule_data, cpu).curr;
printk("+++ (%d.%d) instead idle vcpu on cpu %d\n", vc->domain->domain_id,
vc->vcpu_id, cpu);
dump_runq('q');
BUG();
}
Juergen
--
Juergen Gross Principal Developer Operating Systems
TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28 Internet: ts.fujitsu.com
D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html
next prev parent reply other threads:[~2011-02-03 5:57 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-27 23:18 Hypervisor crash(!) on xl cpupool-numa-split Andre Przywara
2011-01-28 6:47 ` Juergen Gross
2011-01-28 11:07 ` Andre Przywara
2011-01-28 11:44 ` Juergen Gross
2011-01-28 13:14 ` Andre Przywara
2011-01-31 7:04 ` Juergen Gross
2011-01-31 14:59 ` Andre Przywara
2011-01-31 15:28 ` George Dunlap
2011-02-01 16:32 ` Andre Przywara
2011-02-02 6:27 ` Juergen Gross
2011-02-02 8:49 ` Juergen Gross
2011-02-02 10:05 ` Juergen Gross
2011-02-02 10:59 ` Andre Przywara
2011-02-02 14:39 ` Stephan Diestelhorst
2011-02-02 15:14 ` Juergen Gross
2011-02-02 16:01 ` Stephan Diestelhorst
2011-02-03 5:57 ` Juergen Gross [this message]
2011-02-03 9:18 ` Juergen Gross
2011-02-04 14:09 ` Andre Przywara
2011-02-07 12:38 ` Andre Przywara
2011-02-07 13:32 ` Juergen Gross
2011-02-07 15:55 ` George Dunlap
2011-02-08 5:43 ` Juergen Gross
2011-02-08 12:08 ` George Dunlap
2011-02-08 12:14 ` George Dunlap
2011-02-08 16:33 ` Andre Przywara
2011-02-09 12:27 ` George Dunlap
2011-02-09 12:27 ` George Dunlap
2011-02-09 13:04 ` Juergen Gross
2011-02-09 13:39 ` Andre Przywara
2011-02-09 13:51 ` Andre Przywara
2011-02-09 14:21 ` Juergen Gross
2011-02-10 6:42 ` Juergen Gross
2011-02-10 9:25 ` Andre Przywara
2011-02-10 14:18 ` Andre Przywara
2011-02-11 6:17 ` Juergen Gross
2011-02-11 7:39 ` Andre Przywara
2011-02-14 17:57 ` George Dunlap
2011-02-15 7:22 ` Juergen Gross
2011-02-16 9:47 ` Juergen Gross
2011-02-16 13:54 ` George Dunlap
[not found] ` <4D6237C6.1050206@amd.c om>
2011-02-16 14:11 ` Juergen Gross
2011-02-16 14:28 ` Juergen Gross
2011-02-17 0:05 ` André Przywara
2011-02-17 7:05 ` Juergen Gross
2011-02-17 9:11 ` Juergen Gross
2011-02-21 10:00 ` Andre Przywara
2011-02-21 13:19 ` Juergen Gross
2011-02-21 14:45 ` Andre Przywara
2011-02-21 14:50 ` Juergen Gross
2011-02-08 12:23 ` Juergen Gross
2011-01-28 11:13 ` George Dunlap
2011-01-28 13:05 ` Andre Przywara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D4A43B7.5040707@ts.fujitsu.com \
--to=juergen.gross@ts.fujitsu.com \
--cc=Andre.Przywara@amd.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=keir@xen.org \
--cc=stephan.diestelhorst@amd.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).