From: Arjan van de Ven <arjan@linux.intel.com>
To: "Török Edwin" <edwintorok@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>, Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: Strange interaction between latencytop and the scheduler
Date: Tue, 22 Jan 2008 11:04:14 -0800 [thread overview]
Message-ID: <47963E2E.9020501@linux.intel.com> (raw)
In-Reply-To: <47962DD1.9050800@gmail.com>
Török Edwin wrote:
> Hi Arjan, Ingo,
> [for minor latencytop userspace specific issues see at end of mail]
>
> * if I compile with CONFIG_SCHED_DEBUG I see a 30-40msec latency from
> the scheduler, always (Scheduler: waiting for cpu).
> There is also a constant ~5% user, ~2% sys CPU usage on an idle system,
> regardless if latencytop sysctl is on or off.
> Is this normal? (is overhead really 40msec?)
I'm seeing similar, I would not rule out that this is actual scheduler behavior ;(
at least it seems consistent.
I also made a patch (to lkml yesterday) that counts the total and count of scheduler latencies
to also show the cumulative effect of these latencies
> I was also seeing an unusually high number of context switches (as shown
> by vmstat), I usually have 400-800 with non-patched kernels (while
> running mplayer too), but I was getting steadily over 1100 with the
> patch (on idle system).
that's weird; there's nothing blocking in the entire patch at all.
(the only lock is a spinlock)
The performance aspect... collecting the data isn't cheap (which is why it's made a sysctl),
I still plan to look at optimizing it but it won't ever be free.
> * I compile without CONFIG_SCHED_DEBUG, I no longer get *any* latency
> from the scheduler, even if I run multi-threaded programs, etc. Is this
> to be expected? (i.e. is this feature available only when enabling
> CONFIG_SCHED_DEBUG?)
afaik yes.
> Some minor latencytop userspace issues:
> * percentages: new feature (nice!), but the values seem all wrong
> (global perc. are always wrong, per app perc. are usually ok, but see
> second example below)
note that the percentages are percentage this entry had compared the total sum of latencies.
The maximum entry is only loosely related to that; say you have 1 latency in "foo" for 100ms
but 900 of 1ms in "bar", "foo" will show 10% and "bar" will show 90%
> * I miss the Average latency column. If it is too costly to keep account
> of an overall average, can we have last N second average?
it's not costly to calculate, it's the screen space versus the value of the information :(
> * unknown reasons show a backtrace, but backtrace doesn't have enough
> room on screen
still working on that; you can pass the --unknown option to dump these so that I can add them
to the translation table.
next prev parent reply other threads:[~2008-01-22 19:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-22 17:54 Strange interaction between latencytop and the scheduler Török Edwin
2008-01-22 19:04 ` Arjan van de Ven [this message]
2008-01-22 19:35 ` Török Edwin
2008-01-24 9:35 ` Török Edwin
2008-01-24 15:41 ` Arjan van de Ven
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=47963E2E.9020501@linux.intel.com \
--to=arjan@linux.intel.com \
--cc=edwintorok@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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