From: Thomas Gleixner <tglx@linutronix.de>
To: Jeff Dike <jdike@addtoit.com>
Cc: linux-kernel@vger.kernel.org,
"Christopher S. Aker" <caker@theshore.net>,
user-mode-linux-devel@lists.sourceforge.net
Subject: [uml-devel] Re: non-scalar ktime addition and subtraction broken
Date: Fri, 02 Jun 2006 08:54:22 +0200 [thread overview]
Message-ID: <1149231262.20582.119.camel@localhost.localdomain> (raw)
In-Reply-To: <20060602030825.GA8006@ccure.user-mode-linux.org>
On Thu, 2006-06-01 at 23:08 -0400, Jeff Dike wrote:
> The use of 64-bit additions and subtractions on something which is
> nominally a struct containing 32-bit second and nanosecond field is
> broken when a negative time is involved. When the structure is
> treated as a 64-bit integer, the increment of the upper 32 bits that's
> part of two's-complement subtraction is lost. This leaves the end
> result off by one second.
>
> This manifested itself with sleeps inside UML lasting about 1 second
> shorter than expected.
>
> The patch below is more a problem statement than a real fix. People
> thought about performance, and I don't know what this does to that
> work.
>
> I'm not sure why the hrtimer.c part is needed - I had done that before
> tracking down the ktime_add problem. I see short sleeps without it,
> so it is needed somehow.
>
> The ktime_sub piece was done for completeness - UML compiles and boots
> with no apparent ill effects, but it's otherwise untested.
>
> As an aside, I fail to see how it can be correct for ktime_sub to add
> NSEC_PER_SEC to something without compensating somewhere else for it.
>
> Andrew - please don't drop this into -mm without an OK from Thomas or
> someone else who's familiar with this code :-)
NAK. ktime_t is defined that ist must be normalized the same way as
timespecs. The nsec part must be >= 0 and < NSEC_PER_SEC. Fix the part
which is feeding non normalized values.
tglx
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
next prev parent reply other threads:[~2006-06-02 7:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-02 3:08 [uml-devel] non-scalar ktime addition and subtraction broken Jeff Dike
2006-06-02 6:54 ` Thomas Gleixner [this message]
2006-06-02 15:19 ` Jeff Dike
2006-06-02 18:28 ` Blaisorblade
2006-06-02 21:34 ` Jeff Dike
2006-06-04 15:04 ` Blaisorblade
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=1149231262.20582.119.camel@localhost.localdomain \
--to=tglx@linutronix.de \
--cc=caker@theshore.net \
--cc=jdike@addtoit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/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