* [linux-4.1 bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
@ 2015-07-25 2:32 osstest service owner
0 siblings, 0 replies; 2+ messages in thread
From: osstest service owner @ 2015-07-25 2:32 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
test guest-saverestore
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.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: 3a9ace0147d48af49ffd34628f9510f248f2f588
Bug not present: d9c879039393bb14760966bf7076a2d40d45b124
commit 3a9ace0147d48af49ffd34628f9510f248f2f588
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri Jun 12 17:21:41 2015 +0100
tools/libxc+libxl+xl: Restore v2 streams
This is a complicated set of changes which must be done together for
bisectability.
* libxl-save-helper is updated to unconditionally use libxc migration
v2.
* libxl compatibility workarounds in libxc are disabled for restore
operations.
* libxl__stream_read_start() is logically spliced into the event
location where libxl__xc_domain_restore() used to reside.
* Ownership of the save_helper_state moves to stream_read_state.
The parameters 'hvm', 'pae', and 'superpages' were previously
superfluous, and are completely unused in migration
v2. callbacks->toolstack_restore is handled via a migration v2 record
now, rather than via a callback from libxc.
NB: this change breaks Remus. Further untangling needs to happen
before Remus will function.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
---
v4:
* Don't use _init() needlessly
v3:
* Simplify from v2.
* Alter the ownership of save_helper_state
v2:
* Drop "legacy_width" from the IDL
* Gain a LIBXL_HAVE_ to signify support of migration v2 streams
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-4.1/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.guest-saverestore.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Searching for failure / basis pass:
59811 fail [host=merlot0] / 59393 ok.
Failure / basis pass flights: 59811 / 59393
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git
Latest c8bde72f9af412de57f0ceae218d648640118b0b c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 21d9b079e53805b68047d60d28cde224d09bbb40
Basis pass 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c c40317f11b3f05e7c06a2213560c8471081f2662
Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#5cf9896dc5c72a6c68c36140568b755f697f7760-c8bde72f9af412de57f0ceae218d648640118b0b git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#3e2e51ecc1120bd59537ed19b6bc7066511c7e2e-3e2e51ecc1120bd59537ed19b6bc7066511c7e2e git://xenbits.xen.org/staging/qemu-upstream-unstable.git#c4a962ec0c61aa9b860a3635c8424472e6c2cc2c-c4a962ec0c61aa9b860a3635c8424472e6c2cc2c git://xenbits.xen.org/xen.git#c40317f11b3f05e7c06a2213560c8471081f2662-21d9b079e53805b68047d60d28cde224d09bbb40
+ exec
+ sh -xe
+ cd /home/osstest/repos/linux-stable
+ git remote set-url origin git://cache:9419/git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /home/osstest/repos/xen
+ git remote set-url origin git://cache:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /home/osstest/repos/linux-stable
+ git remote set-url origin git://cache:9419/git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /home/osstest/repos/xen
+ git remote set-url origin git://cache:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 52558 nodes in revision graph
Searching for test results:
59393 pass 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c c40317f11b3f05e7c06a2213560c8471081f2662
59826 pass 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c c40317f11b3f05e7c06a2213560c8471081f2662
59873 pass 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c d9c879039393bb14760966bf7076a2d40d45b124
59841 fail c8bde72f9af412de57f0ceae218d648640118b0b c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 21d9b079e53805b68047d60d28cde224d09bbb40
59853 blocked 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 6a3a1951cc357ddbcb21a25d53095d4a44610139
59811 fail c8bde72f9af412de57f0ceae218d648640118b0b c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 21d9b079e53805b68047d60d28cde224d09bbb40
59863 blocked 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c b0f65210b5067d0a063d2bc87ac8a166bddac278
59842 blocked 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 27c5541986667a728a1bf54c63ede8796aab79d8
59855 fail 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c d491d819d3994032360ed5f1117ab71c1a6a765a
59878 fail 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c d77570e70f8c6cc3fc27116aae61bb6b987468fe
59845 pass 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 3bbaaec09b1b942f5624dee176da6e416d31f982
59887 pass 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c d9c879039393bb14760966bf7076a2d40d45b124
59848 fail 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c d1b531631515009281829b736ec050f5d6fb0c63
59857 pass 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c bf4c9d2d0c3fc4fbbf5240e19d21a78f2d0afe37
59851 pass 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c aefc3418c2181eee86309962b64b6f3043a085d3
59860 blocked 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 210b4817529de3eae9db59fee500fcdf0d4a3aa5
59883 fail 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 3a9ace0147d48af49ffd34628f9510f248f2f588
59889 fail 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 3a9ace0147d48af49ffd34628f9510f248f2f588
59891 pass 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c d9c879039393bb14760966bf7076a2d40d45b124
59893 fail 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 3a9ace0147d48af49ffd34628f9510f248f2f588
Searching for interesting versions
Result found: flight 59393 (pass), for basis pass
Result found: flight 59811 (fail), for basis failure
Repro found: flight 59826 (pass), for basis pass
Repro found: flight 59841 (fail), for basis failure
0 revisions at 5cf9896dc5c72a6c68c36140568b755f697f7760 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c d9c879039393bb14760966bf7076a2d40d45b124
No revisions left to test, checking graph state.
Result found: flight 59873 (pass), for last pass
Result found: flight 59883 (fail), for first failure
Repro found: flight 59887 (pass), for last pass
Repro found: flight 59889 (fail), for first failure
Repro found: flight 59891 (pass), for last pass
Repro found: flight 59893 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 3a9ace0147d48af49ffd34628f9510f248f2f588
Bug not present: d9c879039393bb14760966bf7076a2d40d45b124
+ exec
+ sh -xe
+ cd /home/osstest/repos/xen
+ git remote set-url origin git://cache:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
commit 3a9ace0147d48af49ffd34628f9510f248f2f588
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri Jun 12 17:21:41 2015 +0100
tools/libxc+libxl+xl: Restore v2 streams
This is a complicated set of changes which must be done together for
bisectability.
* libxl-save-helper is updated to unconditionally use libxc migration
v2.
* libxl compatibility workarounds in libxc are disabled for restore
operations.
* libxl__stream_read_start() is logically spliced into the event
location where libxl__xc_domain_restore() used to reside.
* Ownership of the save_helper_state moves to stream_read_state.
The parameters 'hvm', 'pae', and 'superpages' were previously
superfluous, and are completely unused in migration
v2. callbacks->toolstack_restore is handled via a migration v2 record
now, rather than via a callback from libxc.
NB: this change breaks Remus. Further untangling needs to happen
before Remus will function.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
---
v4:
* Don't use _init() needlessly
v3:
* Simplify from v2.
* Alter the ownership of save_helper_state
v2:
* Drop "legacy_width" from the IDL
* Gain a LIBXL_HAVE_ to signify support of migration v2 streams
pnmtopng: 215 colors found
Revision graph left in /home/logs/results/bisect/linux-4.1/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.guest-saverestore.{dot,ps,png,html}.
----------------------------------------
59893: tolerable ALL FAIL
flight 59893 linux-4.1 real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/59893/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 11 guest-saverestore fail baseline untested
jobs:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 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
^ permalink raw reply [flat|nested] 2+ messages in thread
* [linux-4.1 bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
@ 2016-07-19 20:28 osstest service owner
0 siblings, 0 replies; 2+ messages in thread
From: osstest service owner @ 2016-07-19 20:28 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.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: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Bug introduced: c5ad33184354260be6d05de57e46a5498692f6d6
Bug not present: c5bcec6cbcbf520f088dc7939934bbf10c20c5a5
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/97670/
commit c5ad33184354260be6d05de57e46a5498692f6d6
Author: Lukasz Odzioba <lukasz.odzioba@intel.com>
Date: Fri Jun 24 14:50:01 2016 -0700
mm/swap.c: flush lru pvecs on compound page arrival
[ Upstream commit 8f182270dfec432e93fae14f9208a6b9af01009f ]
Currently we can have compound pages held on per cpu pagevecs, which
leads to a lot of memory unavailable for reclaim when needed. In the
systems with hundreads of processors it can be GBs of memory.
On of the way of reproducing the problem is to not call munmap
explicitly on all mapped regions (i.e. after receiving SIGTERM). After
that some pages (with THP enabled also huge pages) may end up on
lru_add_pvec, example below.
void main() {
#pragma omp parallel
{
size_t size = 55 * 1000 * 1000; // smaller than MEM/CPUS
void *p = mmap(NULL, size, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS , -1, 0);
if (p != MAP_FAILED)
memset(p, 0, size);
//munmap(p, size); // uncomment to make the problem go away
}
}
When we run it with THP enabled it will leave significant amount of
memory on lru_add_pvec. This memory will be not reclaimed if we hit
OOM, so when we run above program in a loop:
for i in `seq 100`; do ./a.out; done
many processes (95% in my case) will be killed by OOM.
The primary point of the LRU add cache is to save the zone lru_lock
contention with a hope that more pages will belong to the same zone and
so their addition can be batched. The huge page is already a form of
batched addition (it will add 512 worth of memory in one go) so skipping
the batching seems like a safer option when compared to a potential
excess in the caching which can be quite large and much harder to fix
because lru_add_drain_all is way to expensive and it is not really clear
what would be a good moment to call it.
Similarly we can reproduce the problem on lru_deactivate_pvec by adding:
madvise(p, size, MADV_FREE); after memset.
This patch flushes lru pvecs on compound page arrival making the problem
less severe - after applying it kill rate of above example drops to 0%,
due to reducing maximum amount of memory held on pvec from 28MB (with
THP) to 56kB per CPU.
Suggested-by: Michal Hocko <mhocko@suse.com>
Link: http://lkml.kernel.org/r/1466180198-18854-1-git-send-email-lukasz.odzioba@intel.com
Signed-off-by: Lukasz Odzioba <lukasz.odzioba@intel.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Kirill Shutemov <kirill.shutemov@linux.intel.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Vladimir Davydov <vdavydov@parallels.com>
Cc: Ming Li <mingli199x@qq.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-4.1/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-4.1/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install --summary-out=tmp/97670.bisection-summary --basis-template=96211 --blessings=real,real-bisect linux-4.1 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm debian-hvm-install
Searching for failure / basis pass:
97613 fail [host=elbling0] / 96211 [host=fiano1] 96183 [host=chardonnay1] 96160 [host=italia0] 95848 [host=nocera1] 95818 [host=pinot1] 95591 [host=fiano0] 95517 [host=chardonnay0] 95455 [host=pinot0] 95408 [host=huxelrebe0] 94729 [host=chardonnay0] 94034 [host=huxelrebe1] 93220 [host=chardonnay1] 93111 [host=rimava1] 92143 [host=merlot1] 91350 [host=chardonnay0] 91189 [host=huxelrebe0] 91008 ok.
Failure / basis pass flights: 97613 / 91008
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.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 5880876e94699ce010554f483ccf0009997955ca c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f b48be35ac86cd6369124cf06ca3006d086095297
Basis pass 206f91a12c5f69c9b4dfd4e0029043794a046933 c530a75c1e6a472b0eb9558310b518f0dfcd8860 21f6526d1da331611ac5fe12967549d1a04e149b 316a862e5534249a6e6d876b4e203342d3fb870e a6f2cdb633bf519244a16674031b8034b581ba7f
Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#206f91a12c5f69c9b4dfd4e0029043794a046933-5880876e94699ce010554f483ccf0009997955ca git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#21f6526d1da331611ac5fe12967549d1a04e149b-6e20809727261599e8527c456eb078c0e89139a1 git://xenbits.xen.org/qemu-xen.git#316a862e5534249a6e6d876b4e203342d3fb870e-44a072f0de0d57c95c2212bbce02888832b7b74f git://xenbits.xen.org/xen.git#a6f2cdb633bf519244a16674031b8034b581ba7f-b48be35ac86cd6369124cf06ca3006d086095297
Loaded 10934 nodes in revision graph
Searching for test results:
88639 [host=rimava0]
88721 [host=pinot0]
89248 [host=baroque1]
89382 [host=elbling1]
90845 [host=nocera1]
91008 pass 206f91a12c5f69c9b4dfd4e0029043794a046933 c530a75c1e6a472b0eb9558310b518f0dfcd8860 21f6526d1da331611ac5fe12967549d1a04e149b 316a862e5534249a6e6d876b4e203342d3fb870e a6f2cdb633bf519244a16674031b8034b581ba7f
91189 [host=huxelrebe0]
91350 [host=chardonnay0]
92143 [host=merlot1]
93111 [host=rimava1]
93220 [host=chardonnay1]
94034 [host=huxelrebe1]
94729 [host=chardonnay0]
95408 [host=huxelrebe0]
95455 [host=pinot0]
95517 [host=chardonnay0]
95591 [host=fiano0]
95848 [host=nocera1]
95818 [host=pinot1]
96211 [host=fiano1]
96160 [host=italia0]
96183 [host=chardonnay1]
97279 fail irrelevant
97434 fail irrelevant
97394 fail irrelevant
97496 fail 5880876e94699ce010554f483ccf0009997955ca c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f b48be35ac86cd6369124cf06ca3006d086095297
97558 fail 5880876e94699ce010554f483ccf0009997955ca c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f b48be35ac86cd6369124cf06ca3006d086095297
97655 fail c5ad33184354260be6d05de57e46a5498692f6d6 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
97620 fail eae5f796a5de5ebc33e745126ce232f534fd0d0e c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
97601 pass 206f91a12c5f69c9b4dfd4e0029043794a046933 c530a75c1e6a472b0eb9558310b518f0dfcd8860 21f6526d1da331611ac5fe12967549d1a04e149b 316a862e5534249a6e6d876b4e203342d3fb870e a6f2cdb633bf519244a16674031b8034b581ba7f
97642 pass eba391c749fe8a47aea9de2e78fadc02434b5417 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
97626 pass 95123c0b81d9478b8155fe15093b88f57ef7d0bd c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 36c659348837dd411ad6687a76825dd30dd8a419
97605 fail 5880876e94699ce010554f483ccf0009997955ca c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f b48be35ac86cd6369124cf06ca3006d086095297
97630 pass 260c505e55b51645affb70a2c456b350f7e7460a c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
97609 pass 54419e3efcd6677e4b0841666e2fc605d2e5df86 c530a75c1e6a472b0eb9558310b518f0dfcd8860 21f6526d1da331611ac5fe12967549d1a04e149b ae69b059498e8a563c6d64c4aa4cb95e53d76680 75529048f4e81edf4b6af54418976f93a9b90e02
97616 pass 888172862fa78505c4e4674c205a06586443d83f c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 44e6ba4b3376f78315cd447dc88813ba60a83b32
97647 pass c5bcec6cbcbf520f088dc7939934bbf10c20c5a5 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
97631 pass 32dc059d132c7fb4f45a7aeab70e08d2a47ed90d c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
97658 pass c5bcec6cbcbf520f088dc7939934bbf10c20c5a5 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
97636 fail cc6fd729b8a04fbb4b88e45209c1241dd89a3fbe c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
97666 pass c5bcec6cbcbf520f088dc7939934bbf10c20c5a5 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
97613 fail 5880876e94699ce010554f483ccf0009997955ca c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f b48be35ac86cd6369124cf06ca3006d086095297
97650 fail 683854270f84daa09baffe2b21d64ec88c614fa9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
97670 fail c5ad33184354260be6d05de57e46a5498692f6d6 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
97663 fail c5ad33184354260be6d05de57e46a5498692f6d6 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
Searching for interesting versions
Result found: flight 91008 (pass), for basis pass
Result found: flight 97496 (fail), for basis failure
Repro found: flight 97601 (pass), for basis pass
Repro found: flight 97605 (fail), for basis failure
0 revisions at c5bcec6cbcbf520f088dc7939934bbf10c20c5a5 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6e20809727261599e8527c456eb078c0e89139a1 44a072f0de0d57c95c2212bbce02888832b7b74f 7da483b0236d8974cc97f81780dcf8e559a63175
No revisions left to test, checking graph state.
Result found: flight 97647 (pass), for last pass
Result found: flight 97655 (fail), for first failure
Repro found: flight 97658 (pass), for last pass
Repro found: flight 97663 (fail), for first failure
Repro found: flight 97666 (pass), for last pass
Repro found: flight 97670 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Bug introduced: c5ad33184354260be6d05de57e46a5498692f6d6
Bug not present: c5bcec6cbcbf520f088dc7939934bbf10c20c5a5
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/97670/
commit c5ad33184354260be6d05de57e46a5498692f6d6
Author: Lukasz Odzioba <lukasz.odzioba@intel.com>
Date: Fri Jun 24 14:50:01 2016 -0700
mm/swap.c: flush lru pvecs on compound page arrival
[ Upstream commit 8f182270dfec432e93fae14f9208a6b9af01009f ]
Currently we can have compound pages held on per cpu pagevecs, which
leads to a lot of memory unavailable for reclaim when needed. In the
systems with hundreads of processors it can be GBs of memory.
On of the way of reproducing the problem is to not call munmap
explicitly on all mapped regions (i.e. after receiving SIGTERM). After
that some pages (with THP enabled also huge pages) may end up on
lru_add_pvec, example below.
void main() {
#pragma omp parallel
{
size_t size = 55 * 1000 * 1000; // smaller than MEM/CPUS
void *p = mmap(NULL, size, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS , -1, 0);
if (p != MAP_FAILED)
memset(p, 0, size);
//munmap(p, size); // uncomment to make the problem go away
}
}
When we run it with THP enabled it will leave significant amount of
memory on lru_add_pvec. This memory will be not reclaimed if we hit
OOM, so when we run above program in a loop:
for i in `seq 100`; do ./a.out; done
many processes (95% in my case) will be killed by OOM.
The primary point of the LRU add cache is to save the zone lru_lock
contention with a hope that more pages will belong to the same zone and
so their addition can be batched. The huge page is already a form of
batched addition (it will add 512 worth of memory in one go) so skipping
the batching seems like a safer option when compared to a potential
excess in the caching which can be quite large and much harder to fix
because lru_add_drain_all is way to expensive and it is not really clear
what would be a good moment to call it.
Similarly we can reproduce the problem on lru_deactivate_pvec by adding:
madvise(p, size, MADV_FREE); after memset.
This patch flushes lru pvecs on compound page arrival making the problem
less severe - after applying it kill rate of above example drops to 0%,
due to reducing maximum amount of memory held on pvec from 28MB (with
THP) to 56kB per CPU.
Suggested-by: Michal Hocko <mhocko@suse.com>
Link: http://lkml.kernel.org/r/1466180198-18854-1-git-send-email-lukasz.odzioba@intel.com
Signed-off-by: Lukasz Odzioba <lukasz.odzioba@intel.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Kirill Shutemov <kirill.shutemov@linux.intel.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Vladimir Davydov <vdavydov@parallels.com>
Cc: Ming Li <mingli199x@qq.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
dot: graph is too large for cairo-renderer bitmaps. Scaling by 0.344394 to fit
pnmtopng: 42 colors found
Revision graph left in /home/logs/results/bisect/linux-4.1/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.{dot,ps,png,html,svg}.
----------------------------------------
97670: tolerable ALL FAIL
flight 97670 linux-4.1 real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/97670/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail baseline untested
jobs:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 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@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-07-19 20:28 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-25 2:32 [linux-4.1 bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm osstest service owner
2016-07-19 20:28 osstest service owner
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).