| 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
| ||
|
Message-ID: <87wsje79in.fsf@basil.nowhere.org> Date: Tue, 22 Jul 2008 07:50:08 +0200 From: Andi Kleen <andi@...stfloor.org> To: soohoon_lee@...oo.com Cc: linux-kernel@...r.kernel.org Subject: Re: Question: queuing timer interrupts soohoon lee <soohoon_lee@...oo.com> writes: > There is a system and sometimes it should unavoidably block interrupts for critical jobs for couple of 10ms so will lost timer ticks. > But keeping the wall clock is also critical. > I thought about two solutions. > 1. update wall clock when OS gets out of the critical section. > 2. Add a hardware to count lost timer ticks, it's easy for this system. > So when the OS is able to process interrupts again, the hardware generates timer interrupts back to back to compensate lost ticks. noidlehz should handle this all correctly already. You could just treat your critical section like the idle loop and calling all the timer hooks around it. The only subtle issue is that the delay should not exceed the capability of the platform timer to tick without overflow. -Andi -- 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/
Powered by blists - more mailing lists