linux-kernel - Re: In-kernel precise timing.

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] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0610061011500.14591@schroedinger.engr.sgi.com>
Date:	Fri, 6 Oct 2006 10:14:53 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Tommaso Cucinotta <cucinotta@...up.it>
cc:	linux-kernel@...r.kernel.org
Subject: Re: In-kernel precise timing.

On Fri, 6 Oct 2006, Tommaso Cucinotta wrote:

> I'd like to know what is the preferrable way,
> in a Linux kernel module, to get a notification
> at a time in the future so to avoid as much as
> possible unpredictable delays due to possible
> device driver interferences. Basically, I would
> like to use such a mechanism to preempt (also)
> real-time tasks for the purpose of temporally
> isolating them from among each other.
> 
> Is there any prioritary mechanism for specifying
> kind of higher priority timers, to be served as
> soon as possible, vs. lower priority ones, that
> could be e.g. delayed to ksoftirqd and similar ?
> (referring to 2.6.17/18, currently using add_timer(),
> del_timer(), but AFAICS these primitives are more
> appropriate for "timeout" behaviours, rather than
> "precise timing" ones).

This is possible via a hardware interrupt. HPET chips and also the PIT 
provide the ability to schedule an ihterrupts in the future. The periodic 
timer tick is such a mechanism that is also used by the scheduler to 
preempt processes. If the interrupt has sufficiently high priority then 
you could avoid many interrupt holdoffs. However, you may not be able to 
do much since you have no process context. Plus this may be nothing else 
than duplicating already existing functionality.

-
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/