Re: Timekeeping hosed by factor 3, high lapic[01] interrupt rates

From: KAYVEN RIESE <kayve_at_sfsu.edu>
Date: Fri, 24 Jun 2005 15:47:00 -0700 (PDT)
i shouldn't have done this.  my clock is wrong

Path: /home/kayve
(kayve_at_kayvetop) 101> vmsat -i

Whoops>vmstat -i (ynea)? yes
interrupt                          total       rate
irq0: clk                       11619316        999
irq1: atkbd0                       35733          3
irq4: cbb0 bge0                   164070         14
irq7: ppc0                             1          0
irq8: rtc                        1487453        127
irq9: acpi0                          237          0
irq10: fwohci0++                       2          0
irq11: cbb1 uhci0                  98691          8
irq13: npx0                            1          0
irq14: ata0                        32813          2
irq15: ata1                           48          0
Total                           13438365       1156
Path: /home/kayve
(kayve_at_kayvetop) 102>



On Sat, 25 Jun 2005, Jens Schweikhardt wrote:

> John et al,
>
> On Fri, Jun 24, 2005 at 03:28:42PM -0400, John Baldwin wrote:
> # On Friday 24 June 2005 01:53 pm, John Baldwin wrote:
> # > On Friday 24 June 2005 12:50 pm, Jens Schweikhardt wrote:
> # > > On Thu, Jun 23, 2005 at 05:14:39PM -0400, John Baldwin wrote:
> # > > ...
> # > > # Ok.  What timecounter does your UP kernel use, and does your UP kernel
> # > > break # if you change the timecounter to i8254?
> # > >
> # > > The UP uses the TSC:
> # > > $ sysctl -a|grep timec
> # > > kern.timecounter.stepwarnings: 0
> # > > kern.timecounter.nbinuptime: 136311
> # > > kern.timecounter.nnanouptime: 0
> # > > kern.timecounter.nmicrouptime: 664
> # > > kern.timecounter.nbintime: 1273
> # > > kern.timecounter.nnanotime: 36
> # > > kern.timecounter.nmicrotime: 1237
> # > > kern.timecounter.ngetbinuptime: 405
> # > > kern.timecounter.ngetnanouptime: 29
> # > > kern.timecounter.ngetmicrouptime: 2534
> # > > kern.timecounter.ngetbintime: 0
> # > > kern.timecounter.ngetnanotime: 0
> # > > kern.timecounter.ngetmicrotime: 5
> # > > kern.timecounter.nsetclock: 2
> # > > kern.timecounter.hardware: TSC
> # > > kern.timecounter.choice: TSC(800) i8254(0) dummy(-1000000)
> # > > kern.timecounter.tick: 1
> # > > kern.timecounter.smp_tsc: 0
> # > >
> # > > When I do
> # > >
> # > > $ sysctl kern.timecounter.hardware=i8254
> # > >
> # > > on the UP the time dilation by factor 3 starts and the lapic rate
> # > > increases. So yes, that breaks the UP kernel.
> # >
> # > Ok.  Can you try this untested patch?  It's mostly from phk and I haven't
> # > yet tested it locally to make sure it doesn't break things:
> #
> # Scratch that.
>
> (This patch made time advance with 11-fold speed, lapic rates about 170...
> interesting effects happen then ;-)
>
> # I've reproduced this locally now on a testbox I have and had to
> # add a bugfix from phk to get it to work.  Here's the patch that works for me:
>
> Sorry, does not work here; still time dilation in sleep 1 (MP case, no
> sysctl kern.timecounter.hardware frobs):
>
> $ vmstat -i
> interrupt                          total       rate
> irq1: atkbd0                         455          9
> irq13: npx0                            1          0
> irq14: ata0                           63          1
> irq15: ata1                          109          2
> irq18: em0                            15          0
> irq24: ahd0                         4529         96
> irq25: ahc0                           16          0
> lapic0: timer                     272712       5802
> lapic1: timer                     258021       5489
> Total                             535921      11402
>
> Regards,
>
> 	Jens
> --
> Jens Schweikhardt http://www.schweikhardt.net/
> SIGSIG -- signature too long (core dumped)
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>
Received on Fri Jun 24 2005 - 20:47:18 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:37 UTC