From: Jason Wessel <jason.wessel@windriver.com>
To: john stultz <johnstul@us.ibm.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: Problem with commit deda2e81961e96be4f2c09328baca4710a2fd1a0
Date: Fri, 13 Aug 2010 06:53:35 -0500 [thread overview]
Message-ID: <4C65323F.8090907@windriver.com> (raw)
In-Reply-To: <1281684638.3940.11.camel@work-vm>
On 08/13/2010 02:30 AM, john stultz wrote:
> On Thu, 2010-08-12 at 22:17 -0500, Larry Finger wrote:
>
>> On 08/12/2010 03:52 PM, john stultz wrote:
>>
>>> Ugh. I'm surprised it picks *this* loop to optimize instead of the
>>> similar one right above. I'm guessing its the local raw_nsecs value, but
>>> whatever. Also surprised Jason's testing didn't hit this issue, but its
>>> probably a gcc version thing.
>>>
>>> Regardless, I clearly need to give i386 more love in my testing.
>>> My profuse apologies.
>>>
>>> As suggested by Linus, here's the do_div explicit version. It builds ok
>>> on i386 & x86_64, but I have not yet tested it.
>>>
>>> Larry, Jason: Could you verify it works for you (and avoids the original
>>> issue)?
>>>
>> This one builds for me with both compilers. It appears to run OK. As to the
>> original issue - I don't think I ever saw the problem. I'll leave that question
>> for Jason.
>>
>
> Thanks for the testing!
>
> I also managed to trigger the link issue with a 64bit gcc-4.3 cross
> compiling to 32bit. However both 32bit and 64bit gcc-4.4 didn't trigger
> the link issue, so it looks like its fixed in gcc.
>
> Regardless, after my own testing, the change looks good to me. Raw time
> is accumulating properly relative to monotonic time.
>
> Assuming Jason has no complaints it should be able to be pushed in.
>
>
No complaints here. The edge case remains solved on the low MHZ 32 bit
system.
The reason I never saw any problem in all my test configurations was
that gcc 4.4 is the oldest compiler I have in any of the configurations
I am using. I could have been more specific in my original mail on the
subject but it was tested with a 32bit cross compiler as well as a 64bit
cross compiler.
Many thanks to all who helped draw this odd ball case to closure.
Jason.
prev parent reply other threads:[~2010-08-13 11:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-12 20:18 Problem with commit deda2e81961e96be4f2c09328baca4710a2fd1a0 Larry Finger
2010-08-12 20:26 ` Linus Torvalds
2010-08-12 20:41 ` Larry Finger
2010-08-13 8:45 ` Mikael Pettersson
2010-08-12 20:52 ` john stultz
2010-08-13 3:17 ` Larry Finger
2010-08-13 7:30 ` john stultz
2010-08-13 11:53 ` Jason Wessel [this message]
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=4C65323F.8090907@windriver.com \
--to=jason.wessel@windriver.com \
--cc=Larry.Finger@lwfinger.net \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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.