mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Mario 'BitKoenig' Holbe" <Mario.Holbe@RZ.TU-Ilmenau.DE>
To: linux-kernel@vger.kernel.org
Cc: Elrond@Wunder-Nett.org
Subject: /proc/stat interface and 32bit jiffies / kernel_stat
Date: Fri, 15 Nov 2002 15:22:44 +0100	[thread overview]
Message-ID: <20021115142244.GG5957@darkside.ddts.net> (raw)

Hello,

my name is Mario Holbe.
Among others, I'm running a 2-CPU i386 system with a current
uptime of 348 days.

Since around 250 days uptime, we recognize kernel statistics
overflows, which result in serveral problems in HZ calculations
in the procps utilities:

$ uptime
Unknown HZ value! (28) Assume 0.
 14:49:20 up 348 days, 33 min, ...
$ cat /proc/stat
cpu  259658341 5066163 336423925 1117681229
cpu0 129832988 2535697 168074057 2706455735
cpu1 129825353 2530466 168349868 2706192790

As you can see, the 'unused jiffies' counter in the cpu
summary flows over, since 2706455735 + 2706192790 > 2^32.

Besides the general problem, that jiffies and kernel_stat
components are 32bit on i386 platforms:

        sched.h:extern unsigned long volatile jiffies;

  kernel_stat.h:struct kernel_stat {
  kernel_stat.h:	unsigned int per_cpu_user[NR_CPUS],
  kernel_stat.h:	per_cpu_nice[NR_CPUS],
  kernel_stat.h:	per_cpu_system[NR_CPUS];

... and therefor flow over after around 500 days, on SMP
systems the summary calculations in the proc-fs:

    proc_misc.c:	unsigned int sum = 0, user = 0, nice = 0, system = 0;

... already flow over after around 500 / NR_CPUS days,
this means, on a 2-CPU system after around 250 days, on
a 4-CPU system after around 125 days and so on.
[Yes, I know, it's some 2^(32 - round_up(log2(NR_CPUS)))
calculation in real :)]

Resulting in - at least - permanent warnings in procps
utilities.

Since it should not be a big problem to fix this, to
at least reduce the problem back to the 500 days
jiffies-overflow problem, I'd suggest to do so.

No need to mention, that 64bit jiffies and statistics on
all platforms at all would be great :)
Yes, I know the performance implications resulting in this
for 32bit platforms.

Btw... Could anybody please explain me the problems to
expect while a jiffies overflow? Would a kernel possibly
survive this at all and if, what's the chance to? :)


PS: Please CC: me in replies, because I'm not on the list.


regards,
   Mario
-- 
We are the Bore. Resistance is futile. You will be bored.

             reply	other threads:[~2002-11-15 14:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-15 14:22 Mario 'BitKoenig' Holbe [this message]
2002-11-15 15:18 ` Alan Cox
2002-11-15 16:17 ` Tim Schmielau
2002-11-18  5:34 Albert D. Cahalan

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=20021115142244.GG5957@darkside.ddts.net \
    --to=mario.holbe@rz.tu-ilmenau.de \
    --cc=Elrond@Wunder-Nett.org \
    --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

all inboxes | Powered by JetHome®