Userspace shows huge elapsed time across jiffies wrap: with USER_HZ
less then HZ, sys_times needs jiffies_64 to calculate its retval.
--- 2.5.62/kernel/sys.c Sat Feb 15 08:30:12 2003
+++ linux/kernel/sys.c Fri Feb 21 20:41:52 2003
@@ -870,7 +870,7 @@
if (copy_to_user(tbuf, &tmp, sizeof(struct tms)))
return -EFAULT;
}
- return jiffies_to_clock_t(jiffies);
+ return (long) jiffies_64_to_clock_t(get_jiffies_64());
}
/*
On Sat, 22 Feb 2003, Hugh Dickins wrote:
> Userspace shows huge elapsed time across jiffies wrap: with USER_HZ
> less then HZ, sys_times needs jiffies_64 to calculate its retval.
>
> --- 2.5.62/kernel/sys.c Sat Feb 15 08:30:12 2003
> +++ linux/kernel/sys.c Fri Feb 21 20:41:52 2003
> @@ -870,7 +870,7 @@
> if (copy_to_user(tbuf, &tmp, sizeof(struct tms)))
> return -EFAULT;
> }
> - return jiffies_to_clock_t(jiffies);
> + return (long) jiffies_64_to_clock_t(get_jiffies_64());
> }
That makes me wonder, aren't all uses of jiffies_to_clock_t() broken then?
Well, all which take an absolute time as an argument at least.
--Kai
On Sat, 22 Feb 2003, Kai Germaschewski wrote:
> On Sat, 22 Feb 2003, Hugh Dickins wrote:
>
> > Userspace shows huge elapsed time across jiffies wrap: with USER_HZ
> > less then HZ, sys_times needs jiffies_64 to calculate its retval.
>
> That makes me wonder, aren't all uses of jiffies_to_clock_t() broken then?
I believe you're right, but it's less obvious to me that the
other uses really want fixing e.g. would we be happy to maintain
utime,stime,cutime,cstime as 64-bit on a 32-bit machine?
> Well, all which take an absolute time as an argument at least.
Yes, it's much more important to fix those where userspace habitually
takes the difference. That certainly applies to the return value from
sys_times, but I don't see any other cases as clear (though userspace
may have good reason to take the difference of any of them).
Perhaps a procps expert can advise?
Hugh
Hugh Dickins writes:
> On Sat, 22 Feb 2003, Kai Germaschewski wrote:
>> On Sat, 22 Feb 2003, Hugh Dickins wrote:
>>> Userspace shows huge elapsed time across jiffies wrap:
>>> with USER_HZ less then HZ, sys_times needs jiffies_64
>>> to calculate its retval.
>>
>> That makes me wonder, aren't all uses of
>> jiffies_to_clock_t() broken then?
>
> I believe you're right, but it's less obvious to me
> that the other uses really want fixing e.g. would we
> be happy to maintain utime,stime,cutime,cstime as
> 64-bit on a 32-bit machine?
>
>> Well, all which take an absolute time as an argument at least.
>
> Yes, it's much more important to fix those where userspace
> habitually takes the difference. That certainly applies
> to the return value from sys_times, but I don't see any
> other cases as clear (though userspace may have good reason
> to take the difference of any of them).
>
> Perhaps a procps expert can advise?
That depends on how much you care about the problems.
Some that come to mind:
The OOM killer will be more likely to kill the wrong process.
CPU usage stats will be worthless junk.
On a 4-way box, you can hit troubles with cutime after
just 2 weeks of usage.
Consider changing just cutime. It's the value most likely
to wrap. Plain utime would be the second priority.