[...snip..] > > +#ifdef CONFIG_PARAVIRT_SCHED > > + if (pv_sched_enabled() && !in_hardirq() && !local_softirq_pending() && > > + !need_resched() && !task_is_realtime(current)) > > + pv_sched_unboost_vcpu(); > > +#endif > > Symmetry is overrated. Just pick a spot and slap your hackery in. > > Aside of that this whole #ifdeffery is tasteless at best. > > > instrumentation_end(); > > > +#ifdef CONFIG_PARAVIRT_SCHED > > + if (pv_sched_enabled()) > > + pv_sched_boost_vcpu_lazy(); > > +#endif > > But what's worse is that this is just another approach of sprinkling > random hints all over the place and see what sticks. > Understood. WIll have a full re-write of guest side logic for v2. > Abusing KVM as the man in the middle to communicate between guest and > host scheduler is creative, but ill defined. > > From the host scheduler POV the vCPU is just a user space thread and > making the guest special is just the wrong approach. > > The kernel has no proper general interface to convey information from a > user space task to the scheduler. > > So instead of adding some ad-hoc KVM hackery the right thing is to solve > this problem from ground up in a generic way and KVM can just utilize > that instead of having the special snow-flake hackery which is just a > maintainability nightmare. > We had a constructive and productive discussion on the cover letter thread and reaching a consensus on the kvm side of the design. Will work towards that and post iterative revisions. Thanks, Vineeth
