Re: [Xen-devel] [PATCH v2] Modified RTDS scheduler to use an event-driven model instead of polling.

[Dagaen Golomb <dgolomb@xxxxxxxxxxxxxx>]

> That's why at the very beginning of this thread, I asked Dagaen why we
> need to return the position where a VCPU is inserted in the runq.
> Without this assumption, I don't see how we can use the returned
> position of the vcpu in runq in the current patch could be useful.
> But with this assumption, it could be very useful!

Exactly, we keep the runq as-is, but now position/sorting actually
mean something.
If you are in the first # CPUs in the runq is makes sense to be on a pCPU.


> When I proposed the runningq, I was thinking about the situation when
> we decide to split the (old) runq in RT-Xen to the (current) runq and
> depletedq; I was thinking the same reason why we split to runq and
> depletedq may still hold here when we add runningq.
>
> But after thinking twice, maybe runq approach is a better way since it
> just make the position information more meaningful. As you described
> in the previous email, we can compare the position of a vcpu inserted
> into the runq with the number of pCPUs so as to quickly know which
> pCPU to tickle.

[...]

> Actually, nothing bad. I just recalled the situation when we split a
> runq to runq and delpetedq. I was thinking it might be the case here
> as well. (Yes, it is different here since we can get more useful
> information to tickle cpu if we put vCPUs into runq instead of adding
> one more queue.) :-)

I think this is straightforward to simply use the runq. I will work on
this implementation.

Regards,
~Dagaen Golomb

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel