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 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.