Date: Mon, 19 Jul 2010 18:03:40 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Marius Strobl <marius@alchemy.franken.de> Cc: freebsd-sparc64@FreeBSD.org Subject: Re: [RFC] Event timers on sparc64/sun4v Message-ID: <4C44694C.9040108@FreeBSD.org> In-Reply-To: <20100719122423.GA4706@alchemy.franken.de> References: <4C404018.6040405@FreeBSD.org> <20100716213503.GT4706@alchemy.franken.de> <4C42A5B9.7080901@FreeBSD.org> <20100718142101.GY4706@alchemy.franken.de> <4C433391.4080808@FreeBSD.org> <20100719122423.GA4706@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Marius Strobl wrote: > On Sun, Jul 18, 2010 at 08:02:09PM +0300, Alexander Motin wrote: >> 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. I better do it MI way. It's not so difficult. I am just thinking what better report from driver: allowed divisors, periods, or rounding function. >> 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? There is indeed too small info about this. I've found that thing about edge, you've noticed, also I've found that TICK clock is integer multiply of STICK. Taking analogy to x86 I may assume that CPUs with different frequencies still quite likely use same bus frequency (STICK), or even sharing the same bus, while have different multipliers for core (TICK) frequency. It is indeed only an assumption, but it would be strange for CPU designers to implement one more counter, which is not better then already existing one. >> 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). Ah, sorry, found the loop on AP. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C44694C.9040108>