Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 May 2010 20:00:53 +0300
From:      Alexander Motin <mav@FreeBSD.org>
To:        Andriy Gapon <avg@freebsd.org>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: Event timers
Message-ID:  <4BFAB0C5.1020002@FreeBSD.org>
In-Reply-To: <4BFAAA47.5060802@freebsd.org>
References:  <4BFAA1F3.1070206@FreeBSD.org> <4BFAAA47.5060802@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Andriy Gapon wrote:
> on 24/05/2010 18:57 Alexander Motin said the following:
>> I have defined several points on that way:
>> 1*. clean low-level timer drivers from unrelated stuff,
>> 2*. make some common code machine-independent,
>> 3. write common driver API for event timers (alike to one we have now
>> for time counters) to make adding more drivers possible,
>> 4. add support for HPET as event timer in addition to time counter,
>> 5. add support for timers in one-shot mode (LAPIC and HPET).
> 
> I wonder how much you have progressed for 3,4,5.

Not really much yet. Learned existing code and hardware specs, have some
thought and ready to proceed.

> I have some low level code for 4.

I don't see much problems there, except may be interrupt allocation. But
you may send it to me if there is something interesting.

> Some additional things that could be useful:
> a. It would be nice to replace special handling of NULL as interrupt arg with
> something more convenient.  Right now if interrupt arg is NULL then a pointer to
> an interrupted frame is passed to interrupt handler.  This is used by clock
> interrupt handlers.  It would be good to be able to pass both frame pointer and
> some context to handler.  jhb suggested that frame pointer could be passed via
> struct thread.

Hmmm. Interesting question...

> b. On some x86 systems it is possible to broadcast APIC interrupts to all CPUs
> by using broadcast ID (0xFF) instead of a specific CPU ID.  This could be used
> to avoid IPI overhead.
> 
> I have some code for b.

AFAIR I've heart our interrupt code not very supports it... Also IPI
probably could be more selective. We could do for example some form of
one-shot mode using only one simple periodic timer to wake up only
needed cores (plus one initial).

-- 
Alexander Motin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BFAB0C5.1020002>