All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: ltp@lists.linux.it
Subject: [LTP] Memory requirements for ltp
Date: Tue, 26 May 2020 09:54:17 +0100	[thread overview]
Message-ID: <64a5e1c5c8041679e3024b564f2c67ace779c110.camel@linuxfoundation.org> (raw)

Hi,

I work on the Yocto Project and we run ltp tests as part of our testing
infrastructure. We're having problems where the tests hang during
execution and are trying to figure out why as this is disruptive.

It appears to be the controllers tests which hang. Its also clear we
are running the tests on a system with too little memory (512MB) as
there is OOM killer activity all over the logs (as well as errors from
missing tools like nice, bc, gdb, ifconfig and others).

I did dump all the logs and output I could find into a bug for tracking
purposes, https://bugzilla.yoctoproject.org/show_bug.cgi?id=13802

Petr tells me SUSE use 4GB for QEMU, does anyone have any other
boundaries on what works/doesn't work?

Other questions that come to mind:

Could/should ltp test for the tools it uses up front?
Are there any particular tests we should avoid as they are known to be
unreliable?

The ones we're currently running are:

"math", "syscalls", "dio", "io", "mm", "ipc", "sched", "nptl", "pty",
"containers", "controllers", 
"filecaps", "cap_bounds", "fcntl-locktests", "connectors", "commands",
"net.ipv6_lib", "input",
"fs_perms_simple", "fs", "fsx", "fs_bind"

someone suggested I should just remove controllers but I'm not sure
that is the best way forward.

I will test with more memory (not sure how much yet) but I'd welcome
more data if anyone has any.

Cheers,

Richard


             reply	other threads:[~2020-05-26  8:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-26  8:54 Richard Purdie [this message]
2020-05-28 15:13 ` [LTP] Memory requirements for ltp Petr Vorel
2020-06-01 15:06 ` Cyril Hrubis

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=64a5e1c5c8041679e3024b564f2c67ace779c110.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=ltp@lists.linux.it \
    /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.