|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC 1/9] schedule: Introduce per-pcpu time accounting
Hello Julien, On 28.10.19 16:28, Julien Grall wrote: It would be good to get a review from the scheduler maintainers (Dario, George) to make sure they are happy with the suggested states here. I would not say I'm completely happy with this set of states. I'd like to have a discussion on this topic with scheduler maintainers. Also because they could have a different view from x86 world. Introduce per-pcpu time accounting what includes the following states:I think we need a very detailed description of each states. Otherwise it will be hard to know how to categorize it. I agree that we need a very detailed description of each states. Ask questions if something is not clear or doubtful. I guess we could have something better after Q&A process. TACC_HYP - the pcpu executes hypervisor code like softirq processing (including scheduling), tasklets and context switchesIHMO, "like" is too weak here. What do you exactly plan to introduce? I think this should be what hypervisor does except hypercall and IO emulation (what is TACC_GSYNC). For instance, on Arm, you consider that leave_hypervisor_tail() is part of TACC_HYP. This function will include some handling for synchronous trap. I guess you are saying about `p2m_flush_vm`. I doubt here, and open for suggestions. TACC_GUEST - the pcpu executes guests codeLooking at the arm64 code, you are executing some hypervisor code here. I agree this is impossible to not run any hypervisor code with TACC_GUEST, but I think this should be clarified in the documentation. Do you mean adding few words about still having some hypervisor code near the actual context switch from/to guest (entry/return_from_trap)? TACC_IDLE - the low-power state of the pcpuDid you intend to mean "idle vCPU" is in use? No. I did mean what is written. Currently, the idle vcpu does hypervisor work (e.g. tasklets) along with the low-power mode. IMO we have to separate them. TACC_IRQ - the pcpu performs interrupts processing, without separation to guest or hypervisor interrupts TACC_GSYNC - the pcpu executes hypervisor code to process synchronous trap from the guest. E.g. hypercall processing or io emulation. Currently, the only reenterant state is TACC_IRQ. It is assumed, no changes to state other than TACC_IRQ could happen until we return from nested interrupts. IRQ time is accounted in a distinct way comparing to other states.s/comparing/compare/ OK. It is acumulated between other states transition moments, and is substracteds/acumulated/accumulated/ s/substracted/subtracted/ OK. from the old state on states transion calculation. [1] s/transion/transition/ OK. Signed-off-by: Andrii Anisov <andrii_anisov@xxxxxxxx> --- xen/common/schedule.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++ xen/include/xen/sched.h | 27 +++++++++++++++++ 2 files changed, 108 insertions(+) diff --git a/xen/common/schedule.c b/xen/common/schedule.c index 7b71581..6dd6603 100644 --- a/xen/common/schedule.c +++ b/xen/common/schedule.c @@ -1539,6 +1539,87 @@ static void schedule(void) context_switch(prev, next); } +DEFINE_PER_CPU(struct tacc, tacc); + +static void tacc_state_change(enum TACC_STATES new_state)This should never be called with the TACC_IRQ, right? Yes. Actually, tacc->state should never be TACC_IRQ. Because of TACC_IRQ reenterability it is handled through the tacc->irq_cnt and tacc->irq_enter_time.
Place is just a piece of code used for debugging, as well as printk. I keept it here because this series is very RFC, yet it could be removed. Also, is it really necessary to provide helper for each state? Couldn't we just introduce one functions doing all the state? I'd like calling that stuff from assembler without parameters. But have no strong opinion here.
I do lock IRQs for state change. Shouldn't that protect it?
OK. + TACC_HYP = 0,enum begins at 0 and increment by one every time. So there is no need to hardcode a number. Also, looking at the code, I think you rely on the first state to be TACC_HYP. Am I correct? TACC_HYP is expected to be the initial state of the PCPU. + TACC_GUEST = 1, + TACC_IDLE = 2, + TACC_IRQ = 3, + TACC_GSYNC = 4, + TACC_STATES_MAX +};> It would be good to document all the states in the header as well. OK. + +struct taccPlease document the structure. OK.
Yep. + + s_time_t guest_time;This is not used. Yep, will drop it. + + s_time_t irq_enter_time; + s_time_t irq_time; + int irq_cnt;Why do you need this to be signed? For assertion. +}; + +DECLARE_PER_CPU(struct tacc, tacc); + +void tacc_hyp(int place); +void tacc_idle(int place); + #endif /* __SCHED_H__ */ /*Cheers, -- Sincerely, Andrii Anisov. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |