linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Török Edwin" <edwintorok@gmail.com>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] LatencyTop: make reason (blk_execute_rq+0x7a/0xd) known
Date: Sat, 19 Jan 2008 21:47:31 +0200	[thread overview]
Message-ID: <479253D3.4020608@gmail.com> (raw)
In-Reply-To: <479241B0.8010500@linux.intel.com>

Arjan van de Ven wrote:
> Török Edwin wrote:
>>
>> Cause                                               Maximum         
>> Average
>> SCSI device ioctl                                  34.2 msec       
>> 14.4 msec
>
> great! I'll put this into my patchkit!

Thanks.

>> I also noticed some unsigned overflows, my top latency was sometimes a
>> very large number (18................................), which
>> was probably -1, or some other negative number.  I haven't found a way
>> to reproduce it yet (it happens very rarely).
>
>
> I've not seen this; I'll take another peak at the code.

I just captured this:

Cause                                               Maximum          Average
Waiting for userspace lock                        18446744073638300.0
msec        9223372036783524.0 msec
Waiting for processes to die (waitpid)            18446744073638296.0
msec        9223372036783520.0 msec
Waiting for event (poll)                          18446744073565216.0
msec        764505121372.0 msec
SCSI device ioctl                                  35.2 msec        
13.7 msec
Application requested delay                        19.5 msec         
0.0 msec
page fault                                         18.6 msec         
4.0 msec
Reading from file                                  16.6 msec         
1.5 msec
Waiting for buffer IO                              15.2 msec         
3.0 msec
mutex lock                                         15.0 msec        
15.0 msec

I was also looking at /proc/latency_stats using watch, and I've seen
that there were negative number.
Unfortunately I couldn't copy+paste it, because it was gone too fast.

I was running a program with 4 threads doing usleep(0) in an inf-loop.
However I can't reproduce the overflow now with the same program.

Best regards,
--Edwin

      parent reply	other threads:[~2008-01-19 19:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-19 16:54 [PATCH] LatencyTop: make reason (blk_execute_rq+0x7a/0xd) known Török Edwin
2008-01-19 18:30 ` Arjan van de Ven
2008-01-19 19:40   ` Frank Ch. Eigler
2008-01-19 19:47   ` Török Edwin [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=479253D3.4020608@gmail.com \
    --to=edwintorok@gmail.com \
    --cc=arjan@linux.intel.com \
    --cc=linux-kernel@vger.kernel.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 NNTP newsgroup(s).