[Qemu-devel] Re: [PATCH] qemu-kvm: response to SIGUSR1 to start/stop a VCPU (v2)

[Peter Zijlstra]

On Wed, 2010-12-01 at 23:30 +0530, Srivatsa Vaddagiri wrote:
> On Wed, Dec 01, 2010 at 06:45:02PM +0100, Peter Zijlstra wrote:
> > On Wed, 2010-12-01 at 22:59 +0530, Srivatsa Vaddagiri wrote:
> > > 
> > > yield_task_fair(...)
> > > {
> > > 
> > > +       ideal_runtime = sched_slice(cfs_rq, curr);
> > > +       delta_exec = curr->sum_exec_runtime - curr->prev_sum_exec_runtime;
> > > +       rem_time_slice = ideal_runtime - delta_exec;
> > > +
> > > +       current->donate_time += rem_time_slice > some_threshold ?
> > > +                                some_threshold : rem_time_slice;
> > > 
> > >         ...
> > > }
> > > 
> > > 
> > > sched_slice(...)
> > > {
> > >         slice = ...
> > > 
> > > +       slice += current->donate_time;
> > > 
> > > }
> > > 
> > > or something close to it. I am bit reluctant to go that route myself, 
> > > unless the
> > > fairness issue with plain yield is quite bad. 
> > 
> > That really won't do anything. You need to adjust both tasks their
> > vruntime.
> 
> We are dealing with just one task here (the task that is yielding).
> After recording how much timeslice we are "giving up" in current->donate_time
> (donate_time is perhaps not the right name to use), we adjust the yielding
> task's vruntime as per existing logic (for ex: to make it go to back of
> runqueue). When the yielding tasks gets to run again, lock is hopefully 
> available for it to grab, we let it run longer than the default sched_slice()
> to compensate for what time it gave up previously to other threads in same
> runqueue. This ensures that because of yielding upon lock contention, we are 
> not
> leaking bandwidth in favor of other guests. Again I don't know how much of
> fairness issue this is in practice, so unless we see some numbers I'd prefer
> sticking to plain yield() upon lock-contention (for unmodified guests that 
> is).

No, that won't work. Once you've given up time you cannot add it back
without destroying fairness.

You can limit the unfairness by limiting the amount of feedback, but I
really dislike such 'yield' semantics.