linux-kernel - RE: timer interrupt stucks using tickless kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 07 Dec 2009 16:30:12 -0800
From:	john stultz <johnstul@...ibm.com>
To:	Ioannis Kyriakopoulos <johnkyr83@...mail.com>
Cc:	linux-kernel@...r.kernel.org
Subject: RE: timer interrupt stucks using tickless kernel

On Tue, 2009-12-08 at 00:18 +0000, Ioannis Kyriakopoulos wrote:
> >> I have configured my kernel (2.6.31.6) so that I get periodic ticks from
> >> the timer interrupt (i.e. tickless is not configured) with a rate
> determined
> >> by the HZ value. I've also checked the "high resolution timer support"
> >> and also SMP support. The posblem is that the timer is getting
> incremented
> >> very slowly (way slower than the HZ value), just like it would be if the
> >> kernel was tickless. Is there an explanation for that? How can I get
> >> periodic
> >> timer ticks?
> >>
> >> AFAI understand, the HPET timer is used through the IO-APIC controller to
> >> trigger the processors (N.B. if the "High Resolution Timer Support"
> option
> >> wasn't checked, the timer used would  be PIT, right?) and each
> processor's
> >> LAPIC timer is used for time keeping. Please correct me if I am wrong.
> >
> >Not quite, if High Resolution Timers support was disabled, you would
> >still use the HPET hardware instead of the pit, but you'd stay in
> >periodic mode. However, since you have Highres Timers on, the system
> >is using oneshot mode (which is necessary to trigger interrupts faster
> >then HZ), and likely has chosen the LAPIC timer as the interrupt
> >source.
> >
> >In this case, the timer tick becomes an hrt event, that triggers every
> >HZ, instead of being caused by a periodic interrupt.
> 
> OK, so I configured the kernel as follows, expecting to have periodic 
> interrupts by the HPET timer using the PIC controller using only a single
> processor (UP configuration). 
> 
> Unselected: 
> Tickless System (Dynamic Ticks)
> High Resolution Timer Support  
> Symmetric multi-processing support 
> IO-APIC support on uniprocessors (NEW)
> 
> Selected: 
> Local APIC support on uniprocessors
> HPET timer support
>  
> However, when I ran /proc/interrupts, I noticed many weird things:
> 1.	The timer is still not getting incremented at a rate determined by
> HZ.

Right, the system has switched to using the local apic instead of the
PIT or HPET (connected to irq0).


> 2.	When performing cat proc/interrupts, I see that:
>           0:        157   IO-APIC-edge      timer
> 	How the system timer is attached on IO-APIC at the time that the
> IO-APIC 
>       is disabled on kernel configurations? Basically, the timer is not the
> only
>       peripheral attached to IO-APIC as can be seen by /proc/interrupts.
> 
> Here is the output of /proc/interrupts :
> 
>            CPU0
>   0:        157   IO-APIC-edge      timer
>   1:          2   IO-APIC-edge      i8042
>   4:        544   IO-APIC-edge      serial
>   8:          1   IO-APIC-edge      rtc0
>   9:          0   IO-APIC-fasteoi   acpi
>  12:          4   IO-APIC-edge      i8042
>  14:          4   IO-APIC-edge      ata_piix
>  15:          0   IO-APIC-edge      ata_piix
>  16:          0   IO-APIC-fasteoi   uhci_hcd:usb5
>  18:          0   IO-APIC-fasteoi   uhci_hcd:usb4
>  19:         45   IO-APIC-fasteoi   ata_piix, uhci_hcd:usb3
>  22:        149   IO-APIC-fasteoi   HDA Intel
>  23:         72   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
>  27:          0   PCI-MSI-edge      eth0
> NMI:          0   Non-maskable interrupts
> LOC:    1865130   Local timer interrupts
            ^^^
This value should be incrementing at HZ freq.


> SPU:          0   Spurious interrupts
> CNT:          0   Performance counter interrupts
> PND:          0   Performance pending work
> TRM:          0   Thermal event interrupts
> THR:          0   Threshold APIC interrupts
> MCE:          0   Machine check exceptions
> MCP:          7   Machine check polls
> ERR:          0
> MIS:          0
> 
> Is it that difficult to have periodic timer interrupts using HZ rate?

I suspect you already do. If you really want the interrupts to be coming
in via irq0, try booting w/ nolapic.

Is there something your actually having problems with here? Ignoring
which interrupt line is used for the timer event, the system is
functioning properly, right?

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/