Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 31 Aug 2010 08:57:06 -0500
From:      Brandon Gooch <jamesbrandongooch@gmail.com>
To:        Alexander Motin <mav@freebsd.org>
Cc:        freebsd-hackers@freebsd.org, FreeBSD-Current <freebsd-current@freebsd.org>
Subject:   Re: One-shot-oriented event timers management
Message-ID:  <AANLkTi=-bCMJbrh-=d2XUYugAYPWh=32n4nSfxXnfVyZ@mail.gmail.com>
In-Reply-To: <4C7CC1DE.1080907@FreeBSD.org>
References:  <4C7A5C28.1090904@FreeBSD.org> <20100830110932.23425932@ernst.jennejohn.org> <4C7B82EA.2040104@FreeBSD.org> <20100830121148.11926306@ernst.jennejohn.org> <20100831102918.4f5404cc@ernst.jennejohn.org> <4C7CC1DE.1080907@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 31, 2010 at 3:48 AM, Alexander Motin <mav@freebsd.org> wrote:
> Gary Jennejohn wrote:
>> On Mon, 30 Aug 2010 12:11:48 +0200
>> Gary Jennejohn <gljennjohn@googlemail.com> wrote:
>>
>>> On Mon, 30 Aug 2010 13:07:38 +0300
>>> Alexander Motin <mav@FreeBSD.org> wrote:
>>>
>>>> Gary Jennejohn wrote:
>>>>> Hmm. =A0I applied your patches and am now running the new kernel. =A0=
But I
>>>>> only installed the new kernel and didn't do make buildworld installwo=
rld.
>>>>>
>>>>> Mu systat -vm 1 doesn't look anything like yours. =A0I'm seeing about=
 2300
>>>>> interrupts per second and most of those are coming from the hpet time=
rs:
>>>>>
>>>>> 1122 hpet0:t0
>>>>> 1124 hpet0:t1
>>>> It means 1000Hz of hardclock (hz) events mixed with 127Hz of statclock
>>>> (stathz) events. HPET timer here works in one-shot mode handling it.
>>>>
>>>>> So, what else did you do to reduce interrupts so much?
>>>>>
>>>>> Ah, I think I see it now. =A0My desktop has only C1 enabled. =A0Is th=
at it?
>>>>> Unfortunately, it appears that only C1 is supported :(
>>>> Yes, as I have said, at this moment empty ticks skipped only while CPU
>>>> is in C2/C3 states. In C1 state there is no way to handle lost events =
on
>>>> wake up. While it may be not very dangerous, it is not very good.
>>>>
>>> Too bad. =A0I'd say that systems which are limited to C1 don't benefit
>>> much (or not at all) from your changes.
>>>
>>
>> OK, this is purely anecdotal, but I'll report it anyway.
>>
>> I was running pretty much all day with the patched kernel and things
>> seemed to be working quite well.
>>
>> Then, after about 7 hours, everything just stopped.
>>
>> I had gkrellm running and noticed that it updated only when I moved the
>> mouse.
>>
>> This behavior leads me to suspect that the timer interrupts had stopped
>> working and the mouse interrupts were causing processes to get scheduled=
.
>>
>> Unfortunately, I wasn't able to get a dump and had to hit reset to
>> recover.
>>
>> As I wrote above, this is only anecdotal, but I've never seen anything
>> like this before applying the patches.
>
> One-shot timers have one weak side: if for some reason timer interrupt
> getting lost -- there will be nobody to reload the timer. Such cases
> probably will require special attention. Same funny situation with
> mouse-driven scheduler happens also if LAPIC timer dies when pre-Core-iX
> CPU goes to C3 state.

I too had the "freeze" or "pause" when testing with LAPIC, although
I've been using HPET for a while now, and things seem normal:

# systat -vmstat 1

    3 users    Load  0.28  0.33  0.24                  Aug 31 08:48

Mem:KB    REAL            VIRTUAL                       VN PAGER   SWAP PAG=
ER
        Tot   Share      Tot    Share    Free           in   out     in   o=
ut
Act  364524   14244  1600988    17404 1427028  count
All  492712   31000 1075523k    54724          pages
Proc:                                                            Interrupts
  r   p   d   s   w   Csw  Trp  Sys  Int  Sof  Flt        cow     363 total
             74      2153  613 7083  361  144    6      5 zfod        atkbd=
0 1
                                                          ozfod   115 hpet0=
:t0 0
 1.6%Sys   0.4%Intr  2.3%User  0.0%Nice 95.7%Idle        %ozfod    56 hpet0=
:t1 8
|    |    |    |    |    |    |    |    |    |    |       daefr       acpi0=
 9
=3D>                                                        prcfr   187 psm=
0 12
                                        36 dtbuf          totfr       ata0 =
14
Namei     Name-cache   Dir-cache    111105 desvn          react       uhci2=
+ 16
   Calls    hits   %    hits   %      1953 numvn          pdwak       ehci1=
 19
       3       3 100                   327 frevn          pdpgs       uhci0=
 20
                                                          intrn       ehci0=
 22
Disks  ada0   cd0 pass0 pass1                      202356 wire        vgapc=
i0
KB/t   0.00  0.00  0.00  0.00                      200264 act         hdac0=
 258
tps       0     0     0     0                      167392 inact     5 iwn0 =
259
MB/s   0.00  0.00  0.00  0.00                        4208 cache
%busy     0     0     0     0                     1422820 free

# cat /boot/loader.conf:
...
kern.hz=3D"100"
hint.apic.0.clock=3D"0"
hint.atrtc.0.clock=3D"0"
hint.p4tcc.0.disabled=3D"1"
hint.attimer.0.clock=3D0
hint.hpet.0.legacy_route=3D1
hint.acpi_throttle.0.disabled=3D"1"
hw.pci.do_power_nodriver=3D"3"
...

# cat /etc/rc.conf:
...
powerd_enable=3D"YES"
powerd_flags=3D"-a adaptive -b adaptive -n adaptive"
performance_cpu_freq=3D"NONE"     # Online CPU frequency
economy_cpu_freq=3D"NONE"         # Offline CPU frequency
performance_cx_lowest=3D"C3"      # Online CPU idle state
economy_cx_lowest=3D"C3"          # Offline CPU idle state
...

# sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C3
dev.cpu.0.cx_supported: C1/1 C2/1 C3/57
dev.cpu.0.cx_lowest: C3
dev.cpu.0.cx_usage: 0.00% 0.53% 99.46% last 2791us
dev.cpu.1.cx_supported: C1/1 C2/1 C3/57
dev.cpu.1.cx_lowest: C3
dev.cpu.1.cx_usage: 0.00% 1.13% 98.86% last 1492us

Suspend/resume still works well, for what it's worth :)

-Brandon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=-bCMJbrh-=d2XUYugAYPWh=32n4nSfxXnfVyZ>