public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
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


  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).