Re: too short/too long (sys/kern_tc.c)
- From: "Poul-Henning Kamp" <phk@xxxxxxxxxxxxxx>
- Date: Tue, 27 Feb 2007 17:34:23 +0000
In message <45E43984.4020809@xxxxxxxxxxx>, Eric Anderson writes:
When I boot a -CURRENT box with boot verbose enabled inside qemu, I see
one of these messages about every second:
15.f68c5ee76faebe10 too short
16.0f822e13092c5580 too long
This is a symptom of lousy scheduling or even worse interrupt
latency.
In your case +0.060/-0.036 sec per 16 seconds or a couple of percent
in relative terms. (The printf is counter intuitive: the integer
part is in decimal).
I will readily admit that the 1/256 of a second limit is chosen
pretty much at random, but with an eye to allowing a division
by 16 to get close the right result.
All of this futz is of course to avoid floating point in the kernel.
As to why: My main suspect would be the BIOS/ACPI/SMM code, with
a keen eye to the new interrupt filtering code and what it might
do to the clock/scheduling interrupts.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@xxxxxxxxxxx | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: too short/too long (sys/kern_tc.c)
- From: Eric Anderson
- Re: too short/too long (sys/kern_tc.c)
- References:
- too short/too long (sys/kern_tc.c)
- From: Eric Anderson
- too short/too long (sys/kern_tc.c)
- Prev by Date: Re: if_bridge problem
- Next by Date: Re: em0+msi related panic
- Previous by thread: Re: too short/too long (sys/kern_tc.c)
- Next by thread: Re: too short/too long (sys/kern_tc.c)
- Index(es):