[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Re: [PATCH 1/4] CPU online/offline support in Xen
Agree and I ever discussed about this interesting thing with Kevin. So I think he can talk more on this topic. :) Shan Haitao -----Original Message----- From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] Sent: 2008年9月12日 0:53 To: Shan, Haitao; Haitao Shan; Tian, Kevin Cc: xen-devel@xxxxxxxxxxxxxxxxxxx Subject: Re: [Xen-devel] Re: [PATCH 1/4] CPU online/offline support in Xen On 11/9/08 17:00, "Shan, Haitao" <haitao.shan@xxxxxxxxx> wrote: > Hi, Keir, > > Concerning the last running vcpu on the dying cpu, I have some thought. > Yes, there would be a short time after the stop_machine_run when this vcpu > v->processor == dying_cpu. But anyhow, we set fie __VPF_migrating flag for > that vcpu and issued a schedule_softirq on the dying cpu. > This softirq should run immediately after stop_machine context, am I right? If > so, by the time the schedule softirq is executed, this last vcpu is migrated > away from this dying cpu. But saving of its context will be delayed to > play_dead->sync_lazy_context. > If another cpu issues the schedule request to this dying cpu > (vcpu_sleep_nosync->cpu_raise_softirq(vc->processor....)) during this time, > the request will be serviced by the above code sequence. So it is safe in such > cases. > Am I missing something important? I am not quite confident on the statements, > though. I agree it looks safe. By the way, have you considered using this hotplug functionality for power management? If instead of for(;;) halt(); we instead hooked into Cx management and tried to get into as deep sleep as possible (possibly even supporting the really deep sleeps that power off a whole socket and mean you *have* to come back via real mode) then this would give a nice coarse-time-scale power management mechanism controllable from dom0. I consider this might be a nice win for possibly less effort than is being expended in trying to make idle residency times (and hence Cx residency times) as long as possible. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |