public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Bas van der Oest <bassvdo@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: /proc/stat information incorrect
Date: Mon, 16 Apr 2012 14:36:06 +0200	[thread overview]
Message-ID: <20120416143606.2ee7c571@de.ibm.com> (raw)
In-Reply-To: <CABWpNyZkL8K3R=ObOvV9SGMVGTcs1R83H0LSWyXFrQ-Wwb5p+w@mail.gmail.com>

On Mon, 16 Apr 2012 10:04:48 +0200
Bas van der Oest <bassvdo@gmail.com> wrote:

> After dropping some zero columns and taking the difference between the
> statistics the reformatted result is:
>        user    nice    system  idle    iowait  irq     softirq sum
> cpu     5       0       434     7676    0       0       53      8168
> cpu0    0       0       0       1067    0       0       0       1067
> cpu1    0       0       1       1070    0       0       0       1071
> cpu2    0       0       0       1071    0       0       0       1071
> cpu3    1       0       0       1070    0       0       0       1071
> cpu4    1       0       94      974     0       0       0       1069
> cpu5    2       0       92      535     0       0       52      681
> cpu6    0       0       82      987     0       0       0       1069
> cpu7    1       0       165     905     0       0       0       1071
> 
> I added a sum column which totals the time spent in the different
> modes. The above table now shows how long each CPU was in what mode
> for how long.
> Now I am wondering how it is possible that CPU5 has spent much less
> time than all the other CPUs. I expected that all CPUs spent around
> the same time (10s). This time includes idle time so this is not
> related to the difference in active/idle CPUs.
> 
> I know for a fact that this effect is related to which CPU is handling
> my IRQs; this effect happens to all CPUs if I map the interrupts to
> that particular CPU.
> I looked up the scheduler's statistics handling in the kernel source
> but was not able to find any cause for the above mentioned effect.
> 
> Can anyone reproduce this behaviour?
> Does anyone know where/what might be the cause of this?

Assuming that you are on a recent kernel (>= 3.2), could you please
try to revoke git commit a25cac5198d4ff28 "proc: Consider NO_HZ when
printing idle and iowait times" and try again ?

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.


  reply	other threads:[~2012-04-16 12:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-16  8:04 /proc/stat information incorrect Bas van der Oest
2012-04-16 12:36 ` Martin Schwidefsky [this message]
2012-04-17  8:04   ` Bas van der Oest
2012-04-20 12:06     ` Martin Schwidefsky
2012-04-25  7:24       ` Bas van der Oest

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=20120416143606.2ee7c571@de.ibm.com \
    --to=schwidefsky@de.ibm.com \
    --cc=bassvdo@gmail.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