[Xen-devel] Re: [PROPOSAL] Doing work in idle-vcpu context

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 20/04/2010 07:50, "Dulloor" <dulloor@xxxxxxxxx> wrote:

>> George: let me know if the scheduler changes in c/s 21197 look okay.
> 
> George might be able to comment better, but two things :
> 1. Should we not set (ret.time) to some timeslice (rather than -1)
> when we BOOST the idle_vcpu (for csched and csched2).

I purposely skipped that bit of your patch because the idle vcpu will not be
descheduled until it voluntarily re-enters the scheduler, and there is no
tasklet work to do, so it becomes unboosted. The time-slice mechanism is
completely redundant in this scenario so we may as well leave it turned off.

I would have done that in the other two schedulers too, but they still
appear to like to set a real timeout for the idle vcpu. I don't know why,
but George will be able to answer for credit2 at least!

> 2. Is it fine to use a simple list_empty in checking if the
> tasklet_queue is empty for a cpu, with other cpus possibly accessing
> the list too.

The scheduler will always be run through in its entirety at some time after
any change is made to the tasklet_list (because we always raise
SCHEDULE_SOFTIRQ immediately after any such change). As long as the tasklet
is not removed meanwhile it is *guaranteed* that list_empty() will return
false on that subsequent scheduler run-through.

Also note that no matter how clever we make the tasklet_queue_empty()
function, the caller itself is not synchronised to the tasklet subsystem, so
its return value can be stale before the caller even looks at it, no matter
what syncronisation we do before return. Therefore we have to accept that
the scheduler can act on stale/bad information, and simply ensure that in
such cases the scheduler will get run through again very soon after. Hence
the proliferation of [cpu_]raise_softirq() calls in tasklet.c!

 -- Keir




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel