From: Albert Cahalan <albert@users.sf.net>
To: linux-kernel@vger.kernel.org
Cc: hugh@veritas.com, kai@tp1.ruhr-uni-bochum.de
Subject: Re: [PATCH] elapsed times wrap
Date: 24 Feb 2003 17:00:45 -0500 [thread overview]
Message-ID: <1046124046.32116.264.camel@cube> (raw)
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.
next reply other threads:[~2003-02-24 21:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-24 22:00 Albert Cahalan [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-02-22 10:17 [PATCH] elapsed times wrap Hugh Dickins
2003-02-22 22:02 ` Kai Germaschewski
2003-02-23 12:31 ` Hugh Dickins
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=1046124046.32116.264.camel@cube \
--to=albert@users.sf.net \
--cc=hugh@veritas.com \
--cc=kai@tp1.ruhr-uni-bochum.de \
--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 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.