Date: Mon, 19 Jul 2010 14:24:23 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Alexander Motin <mav@FreeBSD.org> Cc: freebsd-sparc64@FreeBSD.org Subject: Re: [RFC] Event timers on sparc64/sun4v Message-ID: <20100719122423.GA4706@alchemy.franken.de> In-Reply-To: <4C433391.4080808@FreeBSD.org> References: <4C404018.6040405@FreeBSD.org> <20100716213503.GT4706@alchemy.franken.de> <4C42A5B9.7080901@FreeBSD.org> <20100718142101.GY4706@alchemy.franken.de> <4C433391.4080808@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 18, 2010 at 08:02:09PM +0300, Alexander Motin wrote:
> Marius Strobl wrote:
> > Looks better, but can't you just implement the tick grace check
> > in tick_et_start() and let it return an error if the interval
> > is too short until there maybe is an MI way to supply a minimum
> > period?
>
> Is it so important now? If I understand right, limit was set at 50KHz. I
> haven't heard somebody was trying to use so high HZ values. And even so,
> 10000 ticks for 500MHz CPU seems much more then enough to handle simple
> read-modify-write operation with disabled interrupts. May be there is
> something wrong with interrupt acknowledgment in case the rest of
> interrupt handler takes too much time or some else? If it is the result
> of some unexpected delays, may be it would be better to reread timer
> after writing comparator to make sure we got in time and plank wasn't
> reached yet?
>
> tick_et_start() status is not checked my MI code at the moment, as error
> handling in that case is not obvious. Do you like panic of printf there?
Ah, I haven't looked at the MI code to closely. No, it's not that
important, a printf should be sufficient for now, I just don't
want the check to get completely dropped.
>
> > Also please follow style(9) and don't initializing variables in
> > the declarations and leave tick_{clear,start} at the end of the
> > file in order to not move code around unnecessarily.
>
> Fixed: http://people.freebsd.org/~mav/timers_sparc3.patch
Looks good, thanks.
>
> Looking on documentation I may assume that STICK counter incremented
> synchronously over the system, while they may need initial sync.
I've no idea how synchronous the (S)TICK counters actually are
across the system over time and with differenct CPU models.
However, at least Linux really jumps through hoops to periodically
synchronize them at runtime over and over again so I assume that
they are not that stable and decided to not rely on their
synchronousity.
Did you come across a description in the documentation saying
that they are in sync, apart from the sentence saying that the
clocks are synchronized at the rising edge?
> Looking
> on sync code I've got some doubts about it's correctness.
>
> If I understand right, BSP waits for AP to signal readiness, then reads
> it's timers and fills respective variable. AP during startup sets
> readiness flag, then fetches value and programs timer. But what happens
> if AP fetches value before the AP stores them? I don't see any
> protection against it there.
You mean when the AP fetches the value before the BSP stores
them? That's dealt with by initializing csa_tick with 0 and
the APs reading csa_tick in a loop until it's not zero. That
variant should result in somewhat better synchronisity than
your version while not hurting the common case. Note that the
membars in there actually should be redundant as the kernel
is run with total store order (but also don't hurt anything).
Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100719122423.GA4706>