From: George Anzinger <george@mvista.com>
To: Andrew Morton <akpm@osdl.org>, john stultz <johnstul@us.ibm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Fw: Re: 2.6.1: process start times by procps
Date: Tue, 27 Jan 2004 17:39:14 -0800 [thread overview]
Message-ID: <401712C2.9060602@mvista.com> (raw)
In-Reply-To: <20040127150850.4f231875.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 3555 bytes --]
Andrew Morton wrote:
> Does this look right to you??
At first blush, no. If it is supposed to be the time of boot then it should be
the same as -wall_to_monotonic.... see below.
>
> Thanks.
>
> Begin forwarded message:
>
> Date: Tue, 27 Jan 2004 17:52:54 +0200
> From: Petri Kaukasoina <kaukasoi@elektroni.ee.tut.fi>
> To: linux-kernel@vger.kernel.org
> Subject: Re: 2.6.1: process start times by procps
>
>
> On Sun, Jan 25, 2004 at 01:08:47PM +0200, I wrote:
>
>>On Fri, Jan 23, 2004 at 09:47:14PM +0200, I wrote:
>>
>>>For example, I started this bash process really at 21:24 (date showed 21:24
>>>then):
>>>
>>>kaukasoi 22108 0.0 0.2 4452 1532 pts/4 R 21:28 0:00 /bin/bash
>>
>>OK, I would like to make my bug report more accurate: the problem seems to
>>be that the value of btime in /proc/stat is not correct.
>
>
> btime in /proc/stat does not stay constant but decreases at a rate of 15
> secs/day. (So I thought that that's why there is that four minute error in
> ps output after uptime of a couple of weeks.) Maybe this has something to do
> with the fact that the 'timer' line in /proc/interrupts does not seem to
> increase at an exact rate of 1000 steps per second but about 1000.18 steps
> per second, instead. (The relative error is the same: 0.18 divided by 1000
> is equal to 15 seconds divided by 24 hours).
>
> I made an experiment shown below. I know nothing about kernel programming,
> so this is probably not correct, but at least btime seemed to stay constant.
> (I don't believe this fixes procps, though. If HZ if off by 180 ppm then I
> guess ps can't possibly get its calculations involving HZ right. But at
> least the bootup time reported by procinfo stays constant.)
>
>
> --- linux-2.6.1/fs/proc/proc_misc.c.orig 2004-01-09 08:59:09.000000000 +0200
> +++ linux-2.6.1/fs/proc/proc_misc.c 2004-01-27 14:39:04.000000000 +0200
> @@ -363,19 +363,13 @@
> u64 jif;
> unsigned int sum = 0, user = 0, nice = 0, system = 0, idle = 0, iowait = 0, irq = 0, softirq = 0;
> struct timeval now;
> - unsigned long seq;
> -
> - /* Atomically read jiffies and time of day */
> - do {
> - seq = read_seqbegin(&xtime_lock);
> -
> - jif = get_jiffies_64();
> - do_gettimeofday(&now);
> - } while (read_seqretry(&xtime_lock, seq));
> + struct timespec uptime;
>
> + do_gettimeofday(&now);
> + do_posix_clock_monotonic_gettime(&uptime);
> /* calc # of seconds since boot time */
> - jif -= INITIAL_JIFFIES;
> - jif = ((u64)now.tv_sec * HZ) + (now.tv_usec/(1000000/HZ)) - jif;
This conversion is the problem. The time.h function timespec_to_jiffies is the
correct way to do this conversion. Still, wall_to_monotonic is defined such that:
posix_clock_monotonic = wall_clock - wall_to_monotonic
This means that - wall_to_monotonic is the value you want and that is, for the
most part a constant, and all that is needed is the second part..
Try the attached.
> + jif = ((u64)now.tv_sec * HZ) + (now.tv_usec/(1000000/HZ)) \
> + - ((u64)uptime.tv_sec * HZ) - (uptime.tv_nsec/(NSEC_PER_SEC/HZ));
> do_div(jif, HZ);
>
> for (i = 0; i < NR_CPUS; i++) {
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
[-- Attachment #2: proc_misc-2.6.1-1.0.patch --]
[-- Type: text/plain, Size: 864 bytes --]
--- linux-2.6.1-org/fs/proc/proc_misc.c 2004-01-26 14:45:25.000000000 -0800
+++ linux/fs/proc/proc_misc.c 2004-01-27 17:32:42.000000000 -0800
@@ -360,23 +360,12 @@
{
int i;
extern unsigned long total_forks;
- u64 jif;
+ unsigned long jif;
unsigned int sum = 0, user = 0, nice = 0, system = 0, idle = 0, iowait = 0, irq = 0, softirq = 0;
- struct timeval now;
- unsigned long seq;
- /* Atomically read jiffies and time of day */
- do {
- seq = read_seqbegin(&xtime_lock);
-
- jif = get_jiffies_64();
- do_gettimeofday(&now);
- } while (read_seqretry(&xtime_lock, seq));
-
- /* calc # of seconds since boot time */
- jif -= INITIAL_JIFFIES;
- jif = ((u64)now.tv_sec * HZ) + (now.tv_usec/(1000000/HZ)) - jif;
- do_div(jif, HZ);
+ jif = - wall_to_monotonic.tv_sec;
+ if (wall_to_monotonic.tv_nsec)
+ --jif;
for (i = 0; i < NR_CPUS; i++) {
int j;
parent reply other threads:[~2004-01-28 1:40 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20040127150850.4f231875.akpm@osdl.org>]
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=401712C2.9060602@mvista.com \
--to=george@mvista.com \
--cc=akpm@osdl.org \
--cc=johnstul@us.ibm.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