From: Keir Fraser <keir.fraser@eu.citrix.com>
To: "Shan, Haitao" <haitao.shan@intel.com>,
Haitao Shan <maillists.shan@gmail.com>,
"Tian, Kevin" <kevin.tian@intel.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: Re: [PATCH 1/4] CPU online/offline support in Xen
Date: Thu, 11 Sep 2008 15:15:14 +0100 [thread overview]
Message-ID: <C4EEE682.2707B%keir.fraser@eu.citrix.com> (raw)
In-Reply-To: <823A93EED437D048963A3697DB0E35DE01C1EB0A@pdsmsx414.ccr.corp.intel.com>
I applied the patch with the following changes:
* I rewrote your changes to fixup_irqs(). We should force lazy EOIs *after*
we have serviced any straggling interrupts. Also we should actually clear
the EOI stack so it is empty next time the CPU comes online.
* I simplified your changes to schedule.c in light of the fact we run in
stop_machine context. Hence we can be quite relaxed about locking, for
example.
* I removed your change to __csched_vcpu_is_migrateable() and instead put a
similar check in csched_load_balance(). I think this is clearer and also
cheaper.
I note that the VCPU currently running on the offlined CPU continues to run
there even after __cpu_disable(), and until that CPU does a final run
through the scheduler soon after. I hope it does not matter there is one
vcpu with v->processor == offlined_cpu for a short while (e.g., what if
another CPU does vcpu_sleep_nosync(v) -> cpu_raise_softirq(v->processor,
...)). I *think* it's actually okay, but I'm not totally certain. Really I
guess this patch needs some stress testing (lots of online/offline cycles
while pausing/unpausing domains, etc). Perhaps we could plumb through a Xen
sysctl and make a small dom0 utility for this purpose?
-- Keir
On 11/9/08 12:33, "Shan, Haitao" <haitao.shan@intel.com> wrote:
> Thanks!
> Concerning cpu online/offline development, I have a small question here.
> Since cpu_online_map is very important, code in different subsystems may use
> it extensively. If such code is not designed with cpu online/offline in mind,
> it may introduce race conditions, just like the one fixed in cpu calibration
> rendezvous.
> Currently, we solve it in a find-and-fix manner. Do you have any idea that can
> solve the problem in a cleaner way?
> Thanks in advance.
>
> Shan Haitao
>
> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com]
> Sent: 2008年9月11日 19:13
> To: Shan, Haitao; Haitao Shan
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Re: [PATCH 1/4] CPU online/offline support in Xen
>
> It looks much better. I'll read through, maybe tweak, and most likely then
> check it in.
>
> Thanks,
> Keir
>
> On 11/9/08 09:02, "Shan, Haitao" <haitao.shan@intel.com> wrote:
>
>> Hi, Keir,
>>
>> Attached is the updated patch using the methods as you described in
>> another mail.
>> What do you think of the one?
>>
>> Signed-off-by: Shan Haitao <haitao.shan@intel.com>
>>
>> Best Regards
>> Haitao Shan
>>
>> Haitao Shan wrote:
>>> Agree. Placing migration in stop_machine context will definitely make
>>> our jobs easier. I will start making a new patch tomorrow. :)
>>> I place the migraton code outside the stop_machine_run context, partly
>>> because I am not quite sure how long it will take to migrate all the
>>> vcpus away. If it takes too much time, all useful works are blocked
>>> since all cpus are in the stop_machine context. Of course, I borrowed
>>> the ideas from kernel, which also let me made the desicion.
>>>
>>> 2008/9/10 Keir Fraser <keir.fraser@eu.citrix.com>:
>>>> I feel this is more complicated than it needs to be.
>>>>
>>>> How about clearing VCPUs from the offlined CPU's runqueue from the
>>>> very end of __cpu_disable()? At that point all other CPUs are safely
>>>> in softirq context with IRQs disabled, and we are running on the
>>>> correct CPU (being offlined). We could have a hook into the
>>>> scheduler subsystem at that point to break affinities, assign to
>>>> different runqueues, etc. We would just need to be careful not to
>>>> try an IPI. :-) This approach would not need a cpu_schedule_map
>>>> (which is really increasing code fragility imo, by creating possible
>>>> extra confusion about which cpumask is the wright one to use in a
>>>> given situation).
>>>>
>>>> My feeling, unless I've missed something, is that this would make
>>>> the patch quite a bit smaller and with a smaller spread of code
>>>> changes.
>>>>
>>>> -- Keir
>>>>
>>>> On 9/9/08 09:59, "Shan, Haitao" <haitao.shan@intel.com> wrote:
>>>>
>>>>> This patch implements cpu offline feature.
>>>>>
>>>>> Best Regards
>>>>> Haitao Shan
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>
>
next prev parent reply other threads:[~2008-09-11 14:15 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-09 8:59 [PATCH 1/4] CPU online/offline support in Xen Shan, Haitao
2008-09-10 10:43 ` Keir Fraser
2008-09-10 10:59 ` Keir Fraser
2008-09-10 12:59 ` Haitao Shan
2008-09-10 16:05 ` Frank van der Linden
2008-09-11 7:36 ` Keir Fraser
2008-09-11 8:02 ` Shan, Haitao
2008-09-11 11:12 ` Keir Fraser
2008-09-11 11:33 ` Shan, Haitao
2008-09-11 12:42 ` Keir Fraser
2008-09-11 14:15 ` Keir Fraser [this message]
2008-09-11 14:23 ` Christoph Egger
2008-09-11 14:32 ` Keir Fraser
2008-09-11 14:47 ` Keir Fraser
2008-09-17 4:17 ` Gavin Maltby
2008-09-17 7:05 ` Jan Beulich
2008-09-17 9:20 ` Jiang, Yunhong
2008-09-17 9:43 ` Christoph Egger
2008-09-17 13:14 ` Ke, Liping
2008-09-18 3:56 ` Jiang, Yunhong
2008-09-18 7:20 ` Keir Fraser
2008-09-18 8:13 ` Jiang, Yunhong
2008-09-18 9:11 ` Keir Fraser
2008-09-18 15:17 ` Jiang, Yunhong
2008-09-11 16:00 ` Shan, Haitao
2008-09-11 16:52 ` Keir Fraser
2008-09-11 23:30 ` Shan, Haitao
-- strict thread matches above, loose matches on Subject: below --
2008-09-12 2:22 Tian, Kevin
2008-09-12 6:02 ` Keir Fraser
2008-09-12 6:04 ` Tian, Kevin
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=C4EEE682.2707B%keir.fraser@eu.citrix.com \
--to=keir.fraser@eu.citrix.com \
--cc=haitao.shan@intel.com \
--cc=kevin.tian@intel.com \
--cc=maillists.shan@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.