xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: anshul makkar <anshul.makkar@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH] credi2-ratelimit: Implement rate limit for credit2 scheduler
Date: Mon, 18 Jul 2016 12:54:34 +0100	[thread overview]
Message-ID: <578CC37A.7020701@citrix.com> (raw)
In-Reply-To: <1468400021.13039.33.camel@citrix.com>

On 13/07/16 09:53, Dario Faggioli wrote:
> On Tue, 2016-07-12 at 17:16 +0100, George Dunlap wrote:
>> On Wed, Jul 6, 2016 at 6:33 PM, Makkar anshul.makkar@citrix.com
>> <Anshul> wrote:
>>>
>>> --- a/xen/common/sched_credit2.c
>>> +++ b/xen/common/sched_credit2.c
>>> +#define MAX_TSLICE(t1, t2)  \
>>> +                   ({ typeof (t1) _t1 = (t1); \
>>> +                      typeof (t1) _t2 = (t2); \
>>> +                      _t1 > _t2 ? _t1 < 0 ? 0 : _t1 : _t2 < 0 ? 0
>>> : _t2; })
>> Hiding the zero-checking behind this seems a bit strange to me.  I
>> think if the algorithm is properly laid out, we probably don't need
>> this at all (see my proposed alternate below).
>>
> I think it's more "overflow-avoidance" than "zero-checking", and as I
> said, that's probably better done by means of subtraction(s).
>
> In any case, I agree that, if we don't need it, that's even better. :-)
Agreed. I am going to remove it. Its not needed with modified algo.
>

>> This is all really confusing.  What about something like this (also
>> attached)?  The basic idea is to calculate min_time, then go through
>> the normal algorithm, then clip it once at the end.
>>
> Yes, this matches my idea and my comment, and I think the code provided
> by George makes sense. Only one thing:
>
>> @@ -1675,9 +1711,19 @@ csched2_runtime(const struct scheduler *ops,
>> int cpu, struct csched2_vcpu *snext
>> +     * or your the ratelimit time.
>>        */
>> +    /* Calculate mintime */
>> +    min_time = CSCHED2_MIN_TIMER;
>> +    if ( prv->ratelimit_us ) {
>> +        s_time_t ratelimit_min = snext->vcpu-
>>> runstate.state_entry_time +
>> +            MICROSECS(prv->ratelimit_us) - now;
>>
> Here snext can indeed be someone which was running already (e.g., we're
> choosing current again), in which case runstate.state_entry-time-now
> would indeed tell us how long it's actually been running, and the
> formula (coupled with the if below) is correct.
>
> But it also can be someone which is runnable (e.g., we're choosing
> someone from the runqueue and preempting current), in which case
> runstate.state_entry_time tells when it became runnable, and
> state_entry_time-now is how long it's been runnable, which is not what
> we want here.
>
> In think, in such a case, we want ratelimit_min to just be equal to
> prv->ratelimit_us. So, maybe, something like this:
>
>   /* Caluclate mintime */
>   min_time = CSCHED2_MIN_TIMER;
>   if ( prv->ratelimit_us )
>   {
>       s_time_t ratelimit_min = prv->ratelimit_us;
>       if ( snext->vcpu->is_running )     // XXX or is it better snext == curr_on_cpu(cpu)
>           ratelimit_min = snext->vcpu->runstate.state_entry_time +
>                           MICROSECS(prv->ratelimit_us) - now;
>       if ( ratelimit_min > min_time )
>           min_time = ratelimit_min;
>   }
>
Agreed.
>>> @@ -2353,6 +2431,8 @@ csched2_init(struct scheduler *ops)
>>>           prv->runq_map[i] = -1;
>>>           prv->rqd[i].id = -1;
>>>       }
>>> +    /* initialize ratelimit */
>>> +    prv->ratelimit_us = 1000 * CSCHED2_MIN_TIMER;
>> Is there any reason this isn't using sched_ratelimit_us (the
>> hypervisor command-line option, which the credit scheduler is using)?
>>
> Yeah, I guess just using that is the best thing to start with.
Agreed.
>
> Regards,
> Dario
>
Will post the reworked patch.

Anshul


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

      parent reply	other threads:[~2016-07-18 11:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-06 17:33 [PATCH] credi2-ratelimit: Implement rate limit for credit2 scheduler Anshul
2016-07-07  9:59 ` Dario Faggioli
2016-07-12 16:16 ` George Dunlap
2016-07-13  8:53   ` Dario Faggioli
2016-07-13 11:08     ` George Dunlap
2016-07-18 11:54     ` anshul makkar [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=578CC37A.7020701@citrix.com \
    --to=anshul.makkar@citrix.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=dario.faggioli@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).