|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-credit2
branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-credit2 testid guest-saverestore Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: ad4b3e1e9df34063d1d6afe6fb3b5eb59d67bbad Bug not present: 7c9283ea1f2af5c495709c34991df64841d78e7c Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/113561/ commit ad4b3e1e9df34063d1d6afe6fb3b5eb59d67bbad Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Date: Thu Sep 14 17:30:36 2017 +0100 xen: credit2: implement utilization cap This commit implements the Xen part of the cap mechanism for Credit2. A cap is how much, in terms of % of physical CPU time, a domain can execute at most. For instance, a domain that must not use more than 1/4 of one physical CPU, must have a cap of 25%; one that must not use more than 1+1/2 of physical CPU time, must be given a cap of 150%. Caps are per domain, so it is all a domain's vCPUs, cumulatively, that will be forced to execute no more than the decided amount. This is implemented by giving each domain a 'budget', and using a (per-domain again) periodic timer. Values of budget and 'period' are chosen so that budget/period is equal to the cap itself. Budget is burned by the domain's vCPUs, in a similar way to how credits are. When a domain runs out of budget, its vCPUs can't run any longer. They can gain, when the budget is replenishment by the timer, which event happens once every period. Blocking the vCPUs because of lack of budget happens by means of a new (_VPF_parked) pause flag, so that, e.g., vcpu_runnable() still works. This is similar to what is done in sched_rtds.c, as opposed to what happens in sched_credit.c, where vcpu_pause() and vcpu_unpause() (which means, among other things, more overhead). Note that, while adding new fields to csched2_vcpu and csched2_dom, currently existing members are being moved around, to achieve best placement inside cache lines. Note also that xenalyze and tools/xentrace/format are being updated too. Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-amd64-xl-credit2.guest-saverestore.html Revision IDs in each graph node refer, respectively, to the Trees above. ---------------------------------------- Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable/test-amd64-amd64-xl-credit2.guest-saverestore --summary-out=tmp/113561.bisection-summary --basis-template=113387 --blessings=real,real-bisect xen-unstable test-amd64-amd64-xl-credit2 guest-saverestore Searching for failure / basis pass: 113543 fail [host=godello0] / 113430 [host=merlot0] 113387 [host=chardonnay0] 113358 [host=elbling1] 113331 [host=huxelrebe1] 113266 [host=rimava0] 113209 [host=merlot1] 113170 [host=baroque0] 113157 [host=huxelrebe0] 112274 [host=elbling1] 112260 [host=baroque1] 112210 [host=merlot0] 112143 [host=fiano1] 112098 [host=elbling0] 112065 ok. Failure / basis pass flights: 113543 / 112065 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d f5a4c84a5d6b19c154abed4ee0380a6f8fd98c60 abd91b2a2bcd05618a71f7e5fe571dd10a5727bc Basis pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 64c3fce24585740a43eb0d589de6e329ca454502 Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#b65f2f457c49b2cfd7967c34b7a0b04c25587f13-4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d git://xenbits.xen.org/qemu-xen.git#414d069b38ab114b89085e44989bf57604ea86d7-f5a4c84a5d6b19c154abed4ee0380a6f8fd98c60 git://xenbits.xen.org/xen.git#64c3fce24585740a43eb0d589de6e329ca454502-abd91b2a2bcd05618a71f7e5fe571dd10a5727bc adhoc-revtuple-generator: tree discontiguous: linux-pvops adhoc-revtuple-generator: tree discontiguous: qemu-xen Loaded 1003 nodes in revision graph Searching for test results: 112098 [host=elbling0] 112065 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 64c3fce24585740a43eb0d589de6e329ca454502 112143 [host=fiano1] 112210 [host=merlot0] 112260 [host=baroque1] 112274 [host=elbling1] 113157 [host=huxelrebe0] 113170 [host=baroque0] 113209 [host=merlot1] 113266 [host=rimava0] 113331 [host=huxelrebe1] 113358 [host=elbling1] 113387 [host=chardonnay0] 113487 fail irrelevant 113430 [host=merlot0] 113460 fail irrelevant 113559 pass 4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d f5a4c84a5d6b19c154abed4ee0380a6f8fd98c60 7c9283ea1f2af5c495709c34991df64841d78e7c 113539 pass 4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d f5a4c84a5d6b19c154abed4ee0380a6f8fd98c60 d5dd9dc86eaad71ccc93cf35826d21d0f859b0c7 113525 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 64c3fce24585740a43eb0d589de6e329ca454502 113504 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 64c3fce24585740a43eb0d589de6e329ca454502 113506 fail irrelevant 113528 fail 4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d f5a4c84a5d6b19c154abed4ee0380a6f8fd98c60 abd91b2a2bcd05618a71f7e5fe571dd10a5727bc 113507 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 09ed69f66d5799cd70f38e458b56a6a65dbead1f 113547 fail 4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d f5a4c84a5d6b19c154abed4ee0380a6f8fd98c60 b182edb70ef5cf209a2b81b0262a635a099c590c 113509 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 bfd19435bca21d3e6c2cfcbb02a143e0e397e7b3 113513 fail irrelevant 113515 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 414d069b38ab114b89085e44989bf57604ea86d7 c286af54c7177c14180121b422d8df7281e547cb 113532 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d f5a4c84a5d6b19c154abed4ee0380a6f8fd98c60 c3d830b244998b3686e2eb64db95996be5eb5e5c 113517 pass irrelevant 113535 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d f5a4c84a5d6b19c154abed4ee0380a6f8fd98c60 30d6ad9efe07146770357ff878e0b5a7306007c2 113519 pass irrelevant 113524 fail 4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d f5a4c84a5d6b19c154abed4ee0380a6f8fd98c60 abd91b2a2bcd05618a71f7e5fe571dd10a5727bc 113521 pass irrelevant 113561 fail 4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d f5a4c84a5d6b19c154abed4ee0380a6f8fd98c60 ad4b3e1e9df34063d1d6afe6fb3b5eb59d67bbad 113511 fail 4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d f5a4c84a5d6b19c154abed4ee0380a6f8fd98c60 abd91b2a2bcd05618a71f7e5fe571dd10a5727bc 113549 pass 4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d f5a4c84a5d6b19c154abed4ee0380a6f8fd98c60 7c9283ea1f2af5c495709c34991df64841d78e7c 113522 pass irrelevant 113537 fail 4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d f5a4c84a5d6b19c154abed4ee0380a6f8fd98c60 fc3986d9632f24ad4d40cffd4cad25298e406122 113554 fail 4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d f5a4c84a5d6b19c154abed4ee0380a6f8fd98c60 ad4b3e1e9df34063d1d6afe6fb3b5eb59d67bbad 113543 fail 4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d f5a4c84a5d6b19c154abed4ee0380a6f8fd98c60 abd91b2a2bcd05618a71f7e5fe571dd10a5727bc 113555 pass 4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d f5a4c84a5d6b19c154abed4ee0380a6f8fd98c60 7c9283ea1f2af5c495709c34991df64841d78e7c 113557 fail 4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d f5a4c84a5d6b19c154abed4ee0380a6f8fd98c60 ad4b3e1e9df34063d1d6afe6fb3b5eb59d67bbad Searching for interesting versions Result found: flight 112065 (pass), for basis pass Result found: flight 113511 (fail), for basis failure Repro found: flight 113525 (pass), for basis pass Repro found: flight 113528 (fail), for basis failure 0 revisions at 4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d f5a4c84a5d6b19c154abed4ee0380a6f8fd98c60 7c9283ea1f2af5c495709c34991df64841d78e7c No revisions left to test, checking graph state. Result found: flight 113549 (pass), for last pass Result found: flight 113554 (fail), for first failure Repro found: flight 113555 (pass), for last pass Repro found: flight 113557 (fail), for first failure Repro found: flight 113559 (pass), for last pass Repro found: flight 113561 (fail), for first failure *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: ad4b3e1e9df34063d1d6afe6fb3b5eb59d67bbad Bug not present: 7c9283ea1f2af5c495709c34991df64841d78e7c Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/113561/ commit ad4b3e1e9df34063d1d6afe6fb3b5eb59d67bbad Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Date: Thu Sep 14 17:30:36 2017 +0100 xen: credit2: implement utilization cap This commit implements the Xen part of the cap mechanism for Credit2. A cap is how much, in terms of % of physical CPU time, a domain can execute at most. For instance, a domain that must not use more than 1/4 of one physical CPU, must have a cap of 25%; one that must not use more than 1+1/2 of physical CPU time, must be given a cap of 150%. Caps are per domain, so it is all a domain's vCPUs, cumulatively, that will be forced to execute no more than the decided amount. This is implemented by giving each domain a 'budget', and using a (per-domain again) periodic timer. Values of budget and 'period' are chosen so that budget/period is equal to the cap itself. Budget is burned by the domain's vCPUs, in a similar way to how credits are. When a domain runs out of budget, its vCPUs can't run any longer. They can gain, when the budget is replenishment by the timer, which event happens once every period. Blocking the vCPUs because of lack of budget happens by means of a new (_VPF_parked) pause flag, so that, e.g., vcpu_runnable() still works. This is similar to what is done in sched_rtds.c, as opposed to what happens in sched_credit.c, where vcpu_pause() and vcpu_unpause() (which means, among other things, more overhead). Note that, while adding new fields to csched2_vcpu and csched2_dom, currently existing members are being moved around, to achieve best placement inside cache lines. Note also that xenalyze and tools/xentrace/format are being updated too. Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> pnmtopng: 135 colors found Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-amd64-xl-credit2.guest-saverestore.{dot,ps,png,html,svg}. ---------------------------------------- 113561: tolerable ALL FAIL flight 113561 xen-unstable real-bisect [real] http://logs.test-lab.xenproject.org/osstest/logs/113561/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: test-amd64-amd64-xl-credit2 15 guest-saverestore fail baseline untested jobs: test-amd64-amd64-xl-credit2 fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |