From: Emmanuel Ackaouy <ack@xensource.com>
To: Atsushi SAKAI <sakaia@jp.fujitsu.com>
Cc: xen-devel@lists.xensource.com, Timo Benk <timo.benk@gmx.de>
Subject: Re: Credit Scheduler not working correct (3.0.4-0)
Date: Thu, 1 Feb 2007 13:16:58 +0100 [thread overview]
Message-ID: <36e876ddaba63377aa1cd1de99a475df@xensource.com> (raw)
In-Reply-To: <200702011133.l11BX2nG032762@fjmscan502.ms.jp.fujitsu.com>
On Feb 1, 2007, at 12:32, Atsushi SAKAI wrote:
> Hi, Emmanuel
>
> I wrote down my guess based on previous study for Timo's cases.
> (I ask you this behavior is specification or not previously.)
> http://lists.xensource.com/archives/html/xen-devel/2006-10/
> msg00365.html
> This case is similar to case 2)
> (when pinned-vcpu credit sum is over 1pcpu capacity)
>
>
> Let's calculate on this.
> Dom1 for 100Weight
> Dom2 for 200Weight
> But CPU resources is 200(2CPU x 100)
> So these credits are Dom1:67 and Dom2:133
> But These vcpus are pinned to pcpu0
> pcpu0 has only 100. but credit total is 200.
> This makes a problem.
>
> These 2vcpu has same priority in credit scheduler,
> since it cannot not consume its credit.
> So these vcpus are scheduled as round robin.
> This makes equal consumption of pcpu0.
>
> Is this wrong guess?
You've described the problem.
Arbitrary pinning makes system wide weighted fair share complex.
Within that problem set there are simple cases where we could easily
do better than now though.
Using cpumasks to take one physical CPU out of the system is one
such case. Arguably, we should have a notion of system partitions
to do this though but in the mean time, we can throw some code
together to not totally bail on weighted fair share when some simpler
uses of pinning are used.
I'll probably have time to look at this next week.
prev parent reply other threads:[~2007-02-01 12:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-01 9:47 Credit Scheduler not working correct (3.0.4-0) Timo Benk
2007-02-01 10:07 ` Atsushi SAKAI
2007-02-01 10:15 ` Timo Benk
2007-02-01 10:25 ` Atsushi SAKAI
2007-02-01 10:30 ` Emmanuel Ackaouy
2007-02-01 10:58 ` Daniele Palumbo
2007-02-06 13:17 ` Emmanuel Ackaouy
2007-02-01 11:06 ` Timo Benk
2007-02-01 11:32 ` Atsushi SAKAI
2007-02-01 12:16 ` Emmanuel Ackaouy [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=36e876ddaba63377aa1cd1de99a475df@xensource.com \
--to=ack@xensource.com \
--cc=sakaia@jp.fujitsu.com \
--cc=timo.benk@gmx.de \
--cc=xen-devel@lists.xensource.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.