From: Clark Williams <williams@redhat.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: pavel <pavel@pavlinux.ru>,
Linux RT Users <linux-rt-users@vger.kernel.org>
Subject: Re: 1us latency?
Date: Thu, 6 Aug 2015 10:03:28 -0500 [thread overview]
Message-ID: <20150806100328.5bd71f63@sluggy> (raw)
In-Reply-To: <20150806131259.GA7924@linutronix.de>
On Thu, 6 Aug 2015 15:12:59 +0200
Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> * Clark Williams | 2015-08-03 13:53:26 [-0500]:
>
> >On Mon, 3 Aug 2015 21:36:26 +0300
> >
> >Interesting. Betting that's page faults and cache filling.
> >
> >I don't think we want to arbitrarily pick some number of cycles for a
> >"settle time" (i.e. a grace period for the application to reach steady
> >state). Possibly we should add an option for that? Specify some number
> >of cycles or some amount of time that where the measurement threads run
> >before actual measurements start?
> >
> > $ cyclictest --numa -p95 -m --settle=10ms
> >
> >That would say "run the measurement threads for ten milliseconds before
> >actually starting the measurement period". That would allow them to
> >fault in and fill cache lines before starting real work.
> >
> >Anyone else have an opinion?
>
> Wouldn't you have everything in-memory after once cycle of each thread?
I had to go through the timerthread() routine a couple of times to
convince myself, but I think you're right.
So if we wanted to discount the paging-in overhead, we could have each
thread do a "dummy" pass through the timer loop (i.e. do everything but
just not record the results) and then start recording measurements. I
may hack together an option to try that and see what sort of results
we get.
Clark
prev parent reply other threads:[~2015-08-06 15:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-03 11:13 1us latency? pavel
2015-08-03 16:44 ` Clark Williams
2015-08-03 17:59 ` pavel
2015-08-03 18:36 ` pavel
2015-08-03 18:53 ` Clark Williams
2015-08-03 19:03 ` pavel
2015-08-04 20:27 ` Frank Rowand
2015-08-06 13:12 ` Sebastian Andrzej Siewior
2015-08-06 15:03 ` Clark Williams [this message]
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=20150806100328.5bd71f63@sluggy \
--to=williams@redhat.com \
--cc=bigeasy@linutronix.de \
--cc=linux-rt-users@vger.kernel.org \
--cc=pavel@pavlinux.ru \
/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.