All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Artem S. Tashkinov" <t.artem@lycos.com>
To: mhocko@suse.cz
Cc: pomac@vapor.com, linux-kernel@vger.kernel.org, rjw@sisk.pl,
	tino.keitel@tikei.de
Subject: Re: Re: [PATCH] proc: Do not overflow get_{idle,iowait}_time for nohz (was: Re: Re: [REGRESSION] [Linux 3.2] top/htop and all other CPU usage)
Date: Fri, 2 Dec 2011 20:12:14 +0000 (GMT)	[thread overview]
Message-ID: <594802130.20617.1322856734286.JavaMail.mail@webmail10> (raw)
In-Reply-To: 20111202175932.GA3894@tiehlicka.suse.cz

On Dec 2, 2011, Michal Hocko wrote: 

> And the one with a more cleaned up changelog. No functional changes
> ---
> From 107887016b91de59194a93c751d040b05d5e37fe Mon Sep 17 00:00:00 2001
> From: Michal Hocko <>
> Date: Fri, 2 Dec 2011 16:17:03 +0100
> Subject: [PATCH] proc: Do not overflow get_{idle,iowait}_time for nohz
> 
> Since a25cac51 [proc: Consider NO_HZ when printing idle and iowait times]
> we are reporting idle/io_wait time also while a CPU is tickless. We rely
> on get_{idle,iowait}_time functions to retrieve proper data.
> 
> These functions, however, use usecs_to_cputime to translate micro
> seconds time to cputime64_t. This is just an alias to usecs_to_jiffies
> which reduces the data type from u64 to unsigned int and also checks
> whether the given parameter overflows jiffies_to_usecs(MAX_JIFFY_OFFSET)
> and returns MAX_JIFFY_OFFSET in that case.
> 
> When do we overflow depends on CONFIG_HZ but especially for
> CONFIG_HZ_300 it is quite low (1431649781) so we are getting
> MAX_JIFFY_OFFSET for >3000s! until we overflow unsigned int.
> Just for reference CONFIG_100 has an overflow window around 20s,
> CONFIG_250 ~8s and CONFIG_1000 ~2s.
> 
> This results in a bug when people saw [h]top going mad reporting 100%
> CPU usage even though there was basically no CPU load. The reason was
> simply that /proc/stat stopped reporting idle/io_wait changes (and
> reported MAX_JIFFY_OFFSET) and so the only change happening was for
> user system time.
> 
> Let's use nsecs_to_jiffies64 instead which doesn't reduce the precision
> to 32b type and it is much more appropriate for cumulative time values
> (unlike usecs_to_jiffies which intended for timeout calculations).
> 
> Signed-off-by: Michal Hocko <mhocko@suse.cz>
> ---
>  fs/proc/stat.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/proc/stat.c b/fs/proc/stat.c
> index 42b274d..2a30d67 100644
> --- a/fs/proc/stat.c
> +++ b/fs/proc/stat.c
> @@ -32,7 +32,7 @@ static cputime64_t get_idle_time(int cpu)
>  		idle = kstat_cpu(cpu).cpustat.idle;
>  		idle = cputime64_add(idle, arch_idle_time(cpu));
>  	} else
> -		idle = usecs_to_cputime(idle_time);
> +		idle = nsecs_to_jiffies64(1000 * idle_time);
>  
>  	return idle;
>  }
> @@ -46,7 +46,7 @@ static cputime64_t get_iowait_time(int cpu)
>  		/* !NO_HZ so we can rely on cpustat.iowait */
>  		iowait = kstat_cpu(cpu).cpustat.iowait;
>  	else
> -		iowait = usecs_to_cputime(iowait_time);
> +		iowait = nsecs_to_jiffies64(1000 * iowait_time);
>  
>  	return iowait;
>  }
> -- 
> 1.7.7.3

Thank you, this patch has fixed the issue for me.

Tested-by: Artem S. Tashkinov <t.artem@mailcity.com>

  reply	other threads:[~2011-12-02 20:12 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-28 22:28 [REGRESSION] [Linux 3.2] top/htop and all other CPU usage pomac
2011-11-29  7:52 ` Michal Hocko
2011-11-29 11:38   ` Artem S. Tashkinov
2011-11-29 12:31     ` Michal Hocko
2011-11-29 12:44       ` Michal Hocko
2011-11-29 12:54         ` Artem S. Tashkinov
2011-11-29 13:10           ` Michal Hocko
2011-11-29 13:51             ` Artem S. Tashkinov
2011-11-29 22:51             ` Rafael J. Wysocki
2011-11-30 10:12               ` Michal Hocko
2011-11-30 19:56                 ` Rafael J. Wysocki
2011-12-01 14:07                   ` Michal Hocko
2011-12-02 10:39                     ` Michal Hocko
2011-12-02 13:35     ` Michal Hocko
2011-12-02 16:49       ` [PATCH] proc: Do not overflow get_{idle,iowait}_time for nohz (was: Re: Re: [REGRESSION] [Linux 3.2] top/htop and all other CPU usage) Michal Hocko
2011-12-02 17:59         ` Michal Hocko
2011-12-02 20:12           ` Artem S. Tashkinov [this message]
2011-12-05  8:56             ` Michal Hocko
2011-12-02 17:43       ` Re: Re: [REGRESSION] [Linux 3.2] top/htop and all other CPU usage Artem S. Tashkinov
2011-11-29 17:23   ` Ian Kumlien
2011-11-29 17:31   ` Ian Kumlien
2011-11-29 17:56     ` Michal Hocko
2011-11-29 18:37       ` Ian Kumlien

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=594802130.20617.1322856734286.JavaMail.mail@webmail10 \
    --to=t.artem@lycos.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@suse.cz \
    --cc=pomac@vapor.com \
    --cc=rjw@sisk.pl \
    --cc=tino.keitel@tikei.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.