WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] credit accounting question

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] credit accounting question
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 19 Jun 2008 13:03:32 +0800
Cc: ackaouy@xxxxxxxxx
Delivery-date: Wed, 18 Jun 2008 22:04:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjRydH7f/H28zBQRE+97te0s5Hyuw==
Thread-topic: credit accounting question
Credit scheduler uses a 10ms timer for vcpu accounting, and 30ms
for system wide accounting. One puzzle from me is whether current
accounting is a bit rough. One vcpu may only execute small quantum,
say 1ms, and then scheduled out. However it's credit may be counted
down by 100 due to 10ms timer expired in between. Then another 
vcpu may execute 18ms, but also with 100 credits substracted if, 
only one tick is hit. Will this result unfair credit assurance in some
pattern? For example:
        cpu0
A:      75 (spin, under) -> current
B:      75 (spin, under)
C:      75 (spin, under)
----
D:      75 (io, under) -> block

'A' first execute 8ms, and then D is waken up:
        cpu0
D:      75 (io, under) -> current
B:      75 (spin, under)
C:      75 (spin, under)
A:      75 (spin, under) -> credit is still 75

'D' execute 1ms, and then sleep again. Now B runs:
        cpu0
B:      75 (spin, under) -> current
C:      75 (spin, under)
A:      75 (spin, under) -> credit is still 75
----
D:      75 (io, under) -> sleep

'B' execute 2ms, with csched_tick triggered in between. Then 'D' is
waken up again:
        cpu0
D:      75 (io, under) -> current
C:      75 (spin, under)
A:      75 (spin, under) -> credit is still 75
B:      -25 (spin, over) -> lower priority

Then the net effect is in last accounting cycle (30ms), 'B' is put
in a lower priority compared to other spin vcpus. Not sure whether
this is an over-sensitive concern in real workload, since above
is just one assumed scenario in my mind. Maybe in reality above
transient unfairness will be fixed in a long run, from average P.O.V.

Simply from design point of view, how much overhead may add
to schedule phase if adding fine-grained accounting there? The 
accounting logic in csched_vcpu_acct seems simple enough.
csched_cpu_pick may be still kept in this 10ms tick, or relax it
to 30ms is also OK?

Thanks,
Kevin

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

<Prev in Thread] Current Thread [Next in Thread>