| Message ID | 981e2a8523db8616a4ed442635a493928376489d.1520589632.git.jstancek@redhat.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | mallocstress: extend test time on arm | expand |
Hi! > Arm systems with lot of memory and THP enabled are > hitting a timeout at ~5 minute mark as reported here: > mallocstress poor performance with THP on arm64 system > https://marc.info/?l=linux-mm&m=151864950330870&w=2 > > Extend the timeout to 10m (only for arm). What about extending it unconditionally? It's not like it will hurt in generall case and there are possible other slow systems that would benefit from that as well. Or do you have a strong reason to extend the timeout only on arm?
----- Original Message ----- > Hi! > > Arm systems with lot of memory and THP enabled are > > hitting a timeout at ~5 minute mark as reported here: > > mallocstress poor performance with THP on arm64 system > > https://marc.info/?l=linux-mm&m=151864950330870&w=2 > > > > Extend the timeout to 10m (only for arm). > > What about extending it unconditionally? It's not like it will hurt in > generall case and there are possible other slow systems that would > benefit from that as well. > > Or do you have a strong reason to extend the timeout only on arm? Just wanted to go with minimal impact on other arches (since they worked OK so far as I'm aware). I don't have strong opinion either way, I can make the timeout unconditional. Regards, Jan
Hi! > Just wanted to go with minimal impact on other arches (since they worked > OK so far as I'm aware). I don't have strong opinion either way, > I can make the timeout unconditional. Given that the test seems to take 4m on successful run 5m timeout seems to be a bit too strict to me. We are not primarily benchmarking the kernel, so these timeouts are better to be set to be double of the expecte runtime. Also I like to avoid #ifdefs whenever possible.
----- Original Message ----- > Hi! > > Just wanted to go with minimal impact on other arches (since they worked > > OK so far as I'm aware). I don't have strong opinion either way, > > I can make the timeout unconditional. > > Given that the test seems to take 4m on successful run 5m timeout seems > to be a bit too strict to me. We are not primarily benchmarking the > kernel, so these timeouts are better to be set to be double of the > expecte runtime. > > Also I like to avoid #ifdefs whenever possible. Pushed with your ACK as unconditional test time change to 10m. Regards, Jan
diff --git a/testcases/kernel/mem/mtest07/mallocstress.c b/testcases/kernel/mem/mtest07/mallocstress.c index 2e900adac28b..fc3bfe7c4e20 100644 --- a/testcases/kernel/mem/mtest07/mallocstress.c +++ b/testcases/kernel/mem/mtest07/mallocstress.c @@ -243,6 +243,14 @@ static void cleanup(void) } static struct tst_test test = { +/* + * extend test time on arm due to: + * "mallocstress poor performance with THP on arm64 system" + * https://marc.info/?l=linux-mm&m=151864950330870&w=2 + */ +#if defined(__arm__) || defined(__aarch64__) + .timeout = 600, +#endif .needs_checkpoints = 1, .setup = setup, .cleanup = cleanup,
Arm systems with lot of memory and THP enabled are hitting a timeout at ~5 minute mark as reported here: mallocstress poor performance with THP on arm64 system https://marc.info/?l=linux-mm&m=151864950330870&w=2 Extend the timeout to 10m (only for arm). Signed-off-by: Jan Stancek <jstancek@redhat.com> --- testcases/kernel/mem/mtest07/mallocstress.c | 8 ++++++++ 1 file changed, 8 insertions(+)