[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] whether xen scheduler supports preemption
Thank you very much for your detail explanation! See below. 在 2013-06-26 09:49:52,"Dario Faggioli" <dario.faggioli@xxxxxxxxxx> 写道: >On mer, 2013-06-26 at 07:37 +0800, 张伟 wrote: >> 在 2013-06-26 07:27:26,"Dario Faggioli" <dario.faggioli@xxxxxxxxxx> 写道: >> >Regarding what you're saying about the "preemption function", I'm sorry, >> >but I cannot parse that part of the sentence... What do you mean by >> >"which part decides it has the preemption function"? >> My meaning is that which code decides the xen scheduler has the preemption ability. >> >Well, the point is it is hard to restrict to a single function (or >anything like that) something like what you call the "preemption >ability". I mean, when you design a scheduler you either design it to be >preemptible or not, and this design choice reflects in many places in >the code... Anyways... > >> In the sched_credit.c file, there is a function, csched_vcpu_wake()->__runq_tickle(), in the function, __runq_tickle(), at the end, there is the following code: >> >... Yes, that is at least most of it. In fact, when a vcpu wakes up, it >is added to a specific runq, and the 'tickling' mechanism is there right >to ensure that the said vcpu starts to run as soon as possible, either >if there are idle pcpus, or the running vcpus have lower priority, the >latter case being the definition of preemption. When a vcpu wakes up, it is added to a specific runq. Whether the specific runq is the runnable queue? either if there are idle pcpus, or the running vcpus have lower priority? I do not understand your meaning. You mean that if there are idle pcpus, the waked up vcpu will be scheduled on the idle pcpus to run. If not, it will preempted the current running vcpus if the waked up vcpu has the higher priority compared to the the current vcpu. Whether my understanding is right? > >> if ( !cpumask_empty(&mask) ) >> cpumask_raise_softirq(&mask, SCHEDULE_SOFTIRQ); >> It will raise SCHEDULE_SOFTIRQ interrupt, whether here decides it has the preemption ability, or other parts? >> >Again, this is probably the most important part of it. The scheduler >runs every time the SCHEDULE_SOFTIRQ interrupt is raised (for a given >pcpu), and the fact that this happens as a consequence of a vcpu waking >up, is what make this particular path a (possible) 'preemption point'. > >If you, for instance, avoid raising the SCHEDULE_SOFTIRQ for busy pcpus >(I would still tickle the idle ones, or you'll get funny results! :-O), >you definitely are making the (credit) scheduler less preemptible. I can not understand here. still tickle the idle ones, or you'll get funny results! What's the meaning? > >Of course, wake-ups is not the only cause of SCHEDULE_SOFTIRQ being >raised. E.g., it fires periodically at the scheduling time slice >boundaries. If you want to avoid vcpus being interrupted by others with >higher priority for this case too, you probably have more paths to tweak >than just the csched_vcpu_wake() function. > Yes, I can not remember the number of raising SCHEDULE_SOFTIRQ interrupt. Long time ago, I check the places of raising SCHEDULE_SOFTIRQ interrupt. It is about seven places. I mean after raising the SCHEDULE_SOFTIRQ interrupt, the handler function schedule() will execute in time or need to wait the current vcpu scheduled out. Which part decides the priority among them?
_______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxx http://lists.xen.org/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |