One-shot-oriented event timers management

[Ian FREISLICH]

Alexander Motin wrote:
> Ian FREISLICH wrote:
> > On Wed, Sep 1, 2010 at 2:16 PM, Alexander Motin <mav at freebsd.org> wrote:
> >> Brandon Gooch wrote:
> >>> This latest patch causes an interrupt storm with the HPET timer on my
> >>> system. The machine took about 8 minutes to boot and bring me to a
> >>> login prompt. System interactivity (i.e. input from keyboard, output
> >>> on console) was fine, but after checking the output of `systat vmstat
> >>> -1`, I saw the interrupt rate on each HPET entry was over 120k!
> >>>
> >>> Can I provide any useful detail? Of course, test patches are always welco
m
> > e :)
> >> I was able to reproduce alike storm in some situations.
> >>
> >> Try new version: http://people.freebsd.org/~mav/timers_oneshot7.patch
> > 
> > Interrupt rates are definitely reduced.
> > 
> > [mini] /usr/home/ianf $ vmstat -i
> > interrupt                          total       rate
> > irq1: atkbd0                        1154          1
> > irq9: acpi0                        10829         15
> > irq16: ath0 uhci3+                 16226         23
> > irq18: uhci2                          16          0
> > irq19: uhci1+                       7090         10
> > irq20: hpet0                      169288        240
> > irq23: uhci0 ehci0                    64          0
> > irq256: hdac0                        187          0
> > Total                             204854        291
> 
> Nice. But 240 still quite a lot. Have you applied tm6292_idle.patch and
> was this system idle at the moment?

No, I didn't.  It was reasonably idle.  I missed that in the first
post - because I became interested in this when Brandon Gooch
reported lower power consumption.  I've compiled now with this patch
as well.  There was one rejection:

--- 2182,2189 ----
         * Ticks is updated asynchronously on a single cpu.  Check here to
         * avoid incrementing ts_ticks multiple times in a single tick.
         */
+ //    if (ts->ts_incrtick == ticks)
+ //            return;
        /* Adjust ticks for pctcpu */
        ts->ts_ticks += 1 << SCHED_TICK_SHIFT;
        ts->ts_ltick = ticks;

But, it appears to have already been applied by timers_oneshot7.patch.

The vmstat -i output is the rate since boot.  Currently at 240/s
since boot, the instantaneous rate when idle is about 60.

> > [mini] /usr/home/ianf $ sysctl dev.cpu |grep usage
> > dev.cpu.0.cx_usage: 0.00% 0.04% 0.80% 99.15% last 1601us
> > dev.cpu.1.cx_usage: 0.00% 0.00% 0.65% 99.34% last 2078us
> 
> It is the first time I see in practice system reporting 4 different ACPI
> C-states. What is this system? What CPU is there? Could you show me full
> `sysctl dev.cpu` output?

It's a compaq mini-110:
CPU: Intel(R) Atom(TM) CPU N270   @ 1.60GHz (1596.22-MHz 686-class CPU)

dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.P001
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 1600
dev.cpu.0.freq_levels: 1600/25000 1400/21875 1333/18000 1166/15750 1067/11000 933/9625 800/5000 700/4375 600/3750 500/3125 400/2500 300/1875 200/1250 100/625
dev.cpu.0.cx_supported: C1/1 C2/1 C3/17 C4/57
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% 0.00% last 379us
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.P002
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
dev.cpu.1.cx_supported: C1/1 C2/1 C3/17 C4/57
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% 0.00% last 4335us

Ian

-- 
Ian Freislich