From: "Turgis, Frederic" <f-turgis@ti.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: Josh Stone <jistone@redhat.com>, Mark Wielaard <mjw@redhat.com>,
"systemtap@sourceware.org" <systemtap@sourceware.org>
Subject: RE: Tune reader_thread poll timeout value
Date: Tue, 15 May 2012 15:29:00 -0000 [thread overview]
Message-ID: <28BE1A38672C8B4481BB423D0FD1F22E18F60C09@DNCE04.ent.ti.com> (raw)
In-Reply-To: <y0mk40dttcf.fsf@fche.csb>
> [...]
> - with high value such as 5 seconds, low throughput trace is dumped
> only every 5s. So of course, do not use probe timer.s(1) to get
> trace dumped every s on command line, you will have 5 correct infos
> in 1 shot every 5s.
>
> - no impact in performance, when trace throughput is high, ppoll()
> returns before timeout expires. [...]
I'm missing something. Why does the second item not moot the first?
IOW, if we poll with a 5s timeout, why wouldn't the timer.s(1) reports
wake up the ppoll() to avoid waiting till 5s?
[FT]
ppoll() wakes-up only when 1 buffer is full. timer.s(1) wakes-up whatever kernel thread (by the way, I should check that with contextswitch trace) but trace throughput is very low. After 5 seconds, ppoll time-outs and the 5 traces done by timer.s(1) at every second are dumped.
When I say "do not use", it is really for interactivity with terminal. People may want to get some small metric every s, but 5 metrics will be displayed every 5s. Of course, for a log read later, you don't care.
So, yes, people should be cautious with this but well, this is for embedded platforms and this is really our goal.
- FChE
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920
next prev parent reply other threads:[~2012-05-15 15:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-01 20:10 Turgis, Frederic
2012-05-01 21:30 ` Frank Ch. Eigler
2012-05-02 8:46 ` Mark Wielaard
2012-05-02 19:39 ` Turgis, Frederic
2012-05-02 20:41 ` Josh Stone
2012-05-03 0:15 ` Turgis, Frederic
2012-05-03 8:33 ` Mark Wielaard
2012-05-07 11:52 ` Turgis, Frederic
2012-05-07 13:56 ` Frank Ch. Eigler
2012-05-07 16:09 ` Turgis, Frederic
2012-05-14 23:59 ` Turgis, Frederic
2012-05-15 14:25 ` Frank Ch. Eigler
2012-05-15 15:29 ` Turgis, Frederic [this message]
2012-05-22 17:53 ` Turgis, Frederic
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=28BE1A38672C8B4481BB423D0FD1F22E18F60C09@DNCE04.ent.ti.com \
--to=f-turgis@ti.com \
--cc=fche@redhat.com \
--cc=jistone@redhat.com \
--cc=mjw@redhat.com \
--cc=systemtap@sourceware.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 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 read-only IMAP folder(s) and NNTP newsgroup(s).