on 21/08/2010 16:04 b. f. said the following: > Andriy Gapon wrote: >> on 21/08/2010 12:35 Andriy Gapon said the following: >>> I feel like you might be having a problem with clocks... >> FWIW, I am reading this document http://edc.intel.com/Link.aspx?id=1484 >> and I see this sentence: "All of the clocks in the processor core are >> stopped in the C3 state". >> >> I see that you have C3 state enabled and it's regularly entered: >> dev.cpu.0.cx_usage: 0.00% 5.51% 94.48% last 305us > > I don't think this accounts for all of his problems, unless his > machine has an unusual configuration. Well, let's try to not muddy the waters prematurely. > Alexander and I recommended > that he try different clocks, and just recently, for example, he wrote > that he had used: > > loader.conf > hint.apic.0.clock="0" > hint.atrtc.0.clock="0" > hint.attimer.0.clock="0" > hint.hpet.0.legacy_route="1" Well, I don't see much point in doing the above in this situation. > machdep.disable_rtc_set="1" > kern.eventtimer.timer2="HPET" > kern.eventtimer.timer1="NONE" (Or, if available, HPET1, ...) So, what was actually used here? I don't think that NONE is a good idea. > kern.eventtimer.singlemul="1" > > sysctl.conf: > kern.timecounter.hardware=HPET > > and reported that it did not help. The HPET doesn't usually suffer > from the problem that you are describing, right? Right. Still I would prefer that Doug would do the cleaner experiment(s) that I suggested. And if the problem persists then elimination of LAPIC timer would make the picture clearer (for me). P.S. I still think that KTR+schedgraph would be the best tool here. --Received on Sat Aug 21 2010 - 13:28:46 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:06 UTC