[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 1/4] xen: add real time scheduler rt



Hi George and Dario,

2014-09-09 5:42 GMT-04:00 Dario Faggioli <dario.faggioli@xxxxxxxxxx>:
> On Mon, 2014-09-08 at 19:44 +0100, George Dunlap wrote:
>> On 09/07/2014 08:40 PM, Meng Xu wrote:
>
>> > +/*
>> > + * update deadline and budget when deadline is in the past,
>> > + * it need to be updated to the deadline of the current period
>> > + */
>> > +static void
>> > +rt_update_helper(s_time_t now, struct rt_vcpu *svc)
>> > +{
>> > +    s_time_t diff = now - svc->cur_deadline;
>> > +
>> > +    if ( diff >= 0 )
>> > +    {
>> > +        /* now can be later for several periods */
>> > +        long count = ( diff/svc->period ) + 1;
>> > +        svc->cur_deadline += count * svc->period;
>> > +        svc->cur_budget = svc->budget;
>>
>> In the common case, don't we expect diff/svc->period to be a small
>> number, like 0 or 1?
>>
> In general, yes. The only exception is when cur_deadline is set for the
> first time. In that case, now can be arbitrary large and cur_deadline
> will always be 0, so quite a few iterations may be required, possibly
> taking longer than the div and the mult.
>
> That is not an hot path anyway, so either approach would be fine in that
> case. For all the other occurrences, the while{} approach is an absolute
> win-win, IMO.
>
>> If so, since division and multiplication are so
>> expensive, it might make more sense to make this a while() loop:
>>
>>   while (now - svc_cur_deadline > 0 )
>>   {
>>    svc->cur_deadline += svc->period;
>>    count++;
>>   }
>>   if ( count ) {
>>    svc->cur_budget = svc->budget;
>>    [tracing code]
>>   }
>>
>> And similarly for the other 64-bit division Dario was asking about below?
>>
> Hehe, this is, I think, the third or fourth time I say I'd like this to
> be turned into a while! :-D
>
> If it were me doing this, I'd go for something like this:
>
>   static void
>   rt_update_helper(s_time_t now, struct rt_vcpu *svc)
>   {
>       if ( svc->cur_deadline > now )
>           return;
>
>       do
>           svc->cur_deadline += svc->period;
>       while ( svc->cur_deadline <= now );
>       svc->cur_budget = svc->budget;
>
>       [tracing]
>   }
>
> Or even just the do {} while (and below), and have the check at the call
> sites (as George is also saying below).

I see the point and will change them for the next version. Thank you
very much! :-)

>
>> I probably wouldn't  make this a precondition of going in.
>>
> No, I'm not strict about this either, we can do it later. I don't think
> it's a big or a too disruptive change, though. :-)
>
>> > +
>> > +        /* TRACE */
>> > +        {
>> > +            struct {
>> > +                unsigned dom:16,vcpu:16;
>> > +                unsigned cur_budget_lo, cur_budget_hi;
>> > +            } d;
>> > +            d.dom = svc->vcpu->domain->domain_id;
>> > +            d.vcpu = svc->vcpu->vcpu_id;
>> > +            d.cur_budget_lo = (unsigned) svc->cur_budget;
>> > +            d.cur_budget_hi = (unsigned) (svc->cur_budget >> 32);
>> > +            trace_var(TRC_RT_BUDGET_REPLENISH, 1,
>> > +                      sizeof(d),
>> > +                      (unsigned char *) &d);
>> > +        }
>> > +
>> > +        return;
>> > +    }
>> > +}
>> > +
>> > +static inline void
>> > +__runq_remove(struct rt_vcpu *svc)
>> > +{
>> > +    if ( __vcpu_on_runq(svc) )
>> > +        list_del_init(&svc->runq_elem);
>> > +}
>> > +
>> > +/*
>> > + * Insert svc in the RunQ according to EDF: vcpus with smaller deadlines
>> > + * goes first.
>> > + */
>> > +static void
>> > +__runq_insert(const struct scheduler *ops, struct rt_vcpu *svc)
>> > +{
>> > +    struct rt_private *prv = RT_PRIV(ops);
>> > +    struct list_head *runq = RUNQ(ops);
>>
> Oh, BTW, George, what do you think about these? The case, I mean. Since
> now they're  static inlines, I've been telling Meng to turn the function
> names lower case.
>
> This is, of course, a minor thing, but since we're saying the are not
> major issues... :-)
>
>> Overall, the code was pretty clean, and easy for me to read -- very much
>> like credit1 and credit2, so thanks. :-)
>>
> Yep, indeed!

Yes, it is. :-)


Thank you very much for your helpful comments and advice! I will
incorporate them in the next version.

Best,

Meng
-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.