Login
[x]
Log in using an account from:
Fedora Account System
Red Hat Associate
Red Hat Customer
Or login using a Red Hat Bugzilla account
Forgot Password
Login:
Hide Forgot
Create an Account
Red Hat Bugzilla – Attachment 317410 Details for
Bug 461184
Significant regression in time() performance
[?]
New
Simple Search
Advanced Search
My Links
Browse
Requests
Reports
Current State
Search
Tabular reports
Graphical reports
Duplicates
Other Reports
User Changes
Plotly Reports
Bug Status
Bug Severity
Non-Defaults
|
Product Dashboard
Help
Page Help!
Bug Writing Guidelines
What's new
Browser Support Policy
5.0.4.rh83 Release notes
FAQ
Guides index
User guide
Web Services
Contact
Legal
This site requires JavaScript to be enabled to function correctly, please enable it.
[patch]
RHEL5 fix for this issue
461184.patch (text/plain), 3.00 KB, created by
Prarit Bhargava
on 2008-09-22 19:15:10 UTC
(
hide
)
Description:
RHEL5 fix for this issue
Filename:
MIME Type:
Creator:
Prarit Bhargava
Created:
2008-09-22 19:15:10 UTC
Size:
3.00 KB
patch
obsolete
>Revert time() syscall changes made in 250708. > >In the past two or three years, RH has not run any gettimeofday() or time() >tests on the RHEL5 kernel because of what appeared to be HW issues. > >I finally upon the real issue behind the problems with gettimeofday() in 250708, >rounding errors were compounding and returning an occasional "off-by-one" >result on gettimeofday() queries. > >After patching the kernel, I turned on the gettimeofday testsuite in RHTS and >noted that all tests but one passed. The test that didn't pass was > >tests/kernel/syscalls/gettimeofday/timedifftest-qa.c > >This test does > >time() >gettimeofday() >time() > >and compares the values to determine if "time" is increasing. If time >decreases, the test fails. > >[Aside: The difference between time() and gettimeofday() is that time() returns >the # of seconds since Jan 1, 1970 and gettimeofday() returns the # of seconds >and microseconds since Jan 1, 1970.] > >The test failed after my initial patch for 250708 because the value returned in >time() does not take into account the amount of time since the last timer >interrupt and "now", whereas gettimeofday() does take this small amount into >account in the calculation. This resulted in an occasional error in the value >that time() reports. > >For example, > >A timer interrupt is handled. t(int) = 10001 seconds > >time() is called and returns t(time) = t(int) = 10001 seconds > >gettimeofday is called and returns t(time) = t(int) + delta(now-t(int)) = 10001 >\+ 1 = 10002 seconds > >time() is called again, and returns t(time) = t(int) = 10001 seconds > >To fix this problem I changed time() to now call gettimeofday() and return the >macroscopic portion of the gettimeofday() calculation. Coincidentally, this >solution matched upstream. > >With the change a call to time() results in a read of the clock which takes >some time and IMO is responsible for the performance hit. > >Without this fix, the timedifftest-qa.c test _will fail_ 100% of the time. >IIRC, a similar test is performed in the ltp testsuite and it will fail as >well. > >However, jturner noted that performance testing on the new time() syscall >resulted in a 2200% increase in the amount of time to call time(). This is >unacceptable so I am reverting this small change which will leave time() >and gettimeofday() unsynchronized in RHEL5. > >Note that this revert does not effect the gettimeofday() syscall modifications. > >jburke has already disabled the timedifftest-qa.c test in RHTS. > >Resolves BZ 461184. > >diff --git a/arch/x86_64/kernel/vsyscall.c b/arch/x86_64/kernel/vsyscall.c >index e8357cd..69719d6 100644 >--- a/arch/x86_64/kernel/vsyscall.c >+++ b/arch/x86_64/kernel/vsyscall.c >@@ -137,17 +137,12 @@ int __vsyscall(0) vgettimeofday(struct timeval * tv, struct timezone * tz) > * unlikely */ > time_t __vsyscall(1) vtime(time_t *t) > { >- struct timeval tv; >- > if (!__sysctl_vsyscall) > return time_syscall(t); >+ else if (t) >+ *t = __xtime.tv_sec; > >- do_vgettimeofday(&tv); >- >- if (t) >- *t = tv.tv_sec; >- >- return tv.tv_sec; >+ return __xtime.tv_sec; > } > > /* Fast way to get current CPU and node.
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
Attachments on
bug 461184
:
317400
| 317410