From: Gautam Thaker <gthaker@comcast.net>
To: linux-kernel@vger.kernel.org
Cc: gthaker@comcast.net
Subject: 2.6.14-rt9 nanosleep() behavior..
Date: Fri, 11 Nov 2005 18:48:16 -0500 [thread overview]
Message-ID: <43752DC0.1050404@comcast.net> (raw)
I have noticed that nanosleep() on 2.6.14-rt9 built with real-time
options listed at bottom of this page has unexpected behavior. In
2.6.13-RC4-RT53 if one called
nanosleep(20msec)
than actual sleep durations were very close to 20msec. (average number
over 1 million samples yielded 20.008msec with minimum of 20.007msec
and maximum of 20.060 msec).
(2.6.13-RC4-RT53 nanosleep(20msec) histogram can be viewed at:
http://www.atl.external.lmco.com/projects/QoS/compare/j_data/linux/2.6.13-RC4-RT-53-07/basement_prio_95_noload_with_chrt_on_pid_8_to_p97_20msec.out.png
with 2.6.14-rt9, nanosleep(20msec) returns average sleep interval of 21
msec.
Is the previously seen behavior in 2.6.13-RC4-RT-53-07 possible now
under latest kernels?
New kernel (2.6.14-rt9) was built with:
Subarchitecture Type (PC-compatible) --->
Processor family (Pentium-Pro) --->
[*] Generic x86 support
[*] HPET Timer Support
[ ] Ktimers 64bit scalar representation
[*] High Resolution Timer Support
(1000) High Resolution Timer resolution (nanoseconds)
[ ] Symmetric multi-processing support
Preemption Mode (Complete Preemption (Real-Time)) --->
--- Thread Softirqs
--- Thread Hardirqs
--- Preemptible RCU
[*] /proc stats for preemptible RCU read-side critical sections
[ ] /proc torture tests for RCU
[ ] Local APIC support on uniprocessors
[*] Machine Check Exception
< > Check for non-fatal errors on AMD Athlon/Duron / Intel Pentium
<M> Toshiba Laptop support
<M> Dell laptop support
[ ] Enable X86 board specific fixups for reboot
<M> /dev/cpu/microcode - Intel IA32 CPU microcode support
<M> /dev/cpu/*/msr - Model-specific register support
<M> /dev/cpu/*/cpuid - CPU information support
Firmware Drivers --->
High Memory Support (4GB) --->
Memory model (Flat Memory) --->
[*] Allocate 3rd-level pagetables from highmem
[ ] Math emulation
[*] MTRR (Memory Type Range Register) support
[ ] Boot from EFI support (EXPERIMENTAL)
[*] Use register arguments (EXPERIMENTAL)
[*] Enable seccomp to safely compute untrusted bytecode
Timer frequency (1000 HZ) --->
[ ] kexec system call (EXPERIMENTAL)
reply other threads:[~2005-11-11 23:48 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=43752DC0.1050404@comcast.net \
--to=gthaker@comcast.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox