All of lore.kernel.org
 help / color / mirror / Atom feed
From: Clark Williams <williams@redhat.com>
To: Matthieu Bec <mbec@gmto.org>
Cc: Steven Rostedt <rostedt@goodmis.org>, linux-rt-users@vger.kernel.org
Subject: Re: good load / stress suite?
Date: Wed, 16 May 2012 10:55:01 -0500	[thread overview]
Message-ID: <20120516105501.17018110@redhat.com> (raw)
In-Reply-To: <1337133337.6724.24.camel@gandalf.stny.rr.com>

[-- Attachment #1: Type: text/plain, Size: 2990 bytes --]

On Tue, 15 May 2012 21:55:37 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Tue, 2012-05-15 at 16:08 -0700, Matthieu Bec wrote:
> > Hello all,
> > 
> > I was wondering what people used to check RT_PREEMPT behavior under 
> > load/stress?
> 
> There is a test suite that Red Hat uses called rt-eval (I believe).
> Clark can give you more info on that.

It's called rteval and I have a git tree here:

git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rteval.git

It's basically some python scripting to do much of what Steven describes
below. When it starts up it kicks off a kernel make with 2* the number
of available processors (make -j <n*2>) and runs hackbench, both in
loop. Then it kicks off cyclictest to measure the system latency under
load. 

I usually run it like this:

	$ sudo rteval --duration=12h

At the end it summarizes the results of the run.

> 
> > 
> > I'm trying to test the accuracy of my timers and have a test where I 
> > setup a kernel module with an hr-timer flipping RTS bit on serial COM0 
> > periodically, which I can look on an oscilloscope. the scope triggers on 
> > rising edge, I call jitter what shows on the falling side:
> > under no specific load I get ~ 10 us (worst case waiting a long time)
> > 
> > 
> > My initial idea for stressing the system was to compile a kernel, make 
> > -j 8 (#cores) that I thought would exercise CPU and IO if anything. As 
> > it happens, it's "mostly good" but I do get occasional (but repeatable) 
> > wild excursions (>100us)
> 
> The tests I do is the following:
> 
> I run "cyclictest -n -p 80 -t -i 250" then in another window I run a
> kernel compile using distcc (to stress the network as well) with make
> -j40, it basically does:
> 
> while :; make clean; make -j40; done
> 
> Then I also run hackbench (written by Rusty Russell), with:
> 
> while :; hackbench 50 ; done
> 
> I run the above on a single machine, while on another machine I run
> ktest against the -rt kernel to test different configs (with and without
> PREEMPT_RT enabled and such). I do this for both i386 and x86_64.
> 
> 
> > 
> > Looking around, I found a tool called 'stress' - 
> > http://weather.ou.edu/~apw/projects/stress/
> > Under these new conditions, the system behaves really well again ~20 us 
> > stable all the way.
> > 
> > So both tests give different result, I'm not sure which to trust.
> > I was thinking maybe there is some weird interaction with the kernel and 
> > building the kernel that make the 'bad' test invalid?
> > 
> > I have RT_PREEMPT 3.0.18-rt34 SMP x86_64
> > 
> 
> Now, I run the above stress tests that I mentioned for several hours
> before I release a stable kernel. I run this on a 2.6GHz xeon core2, and
> I may hit at most 70us latency with cyclictest. That's a high, it
> usually stays below 50us. We consider >100us on this type of hardware a
> bug which needs to be fixed.
> 
> -- Steve
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2012-05-16 15:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-15 23:08 good load / stress suite? Matthieu Bec
2012-05-16  1:55 ` Steven Rostedt
2012-05-16 15:55   ` Clark Williams [this message]
2012-05-19  0:17     ` Matthieu Bec

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=20120516105501.17018110@redhat.com \
    --to=williams@redhat.com \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mbec@gmto.org \
    --cc=rostedt@goodmis.org \
    /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.