From owner-freebsd-sparc64@FreeBSD.ORG Mon Jul 19 15:04:51 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A7091065672 for ; Mon, 19 Jul 2010 15:04:51 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id A7A3B8FC16 for ; Mon, 19 Jul 2010 15:04:50 +0000 (UTC) Received: by fxm13 with SMTP id 13so2454038fxm.13 for ; Mon, 19 Jul 2010 08:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=jg59H+ZT34OCZRA6WzAGcZz8xp1giWKp+62aFVX19Bs=; b=rp9tdeb0n5kd3B3w66EzSHO07FAhxHFRFcZ8w0FfWC4Vc9yUww/B/PF6GNCnwVlXhK TFMcmQ9hQqU1yB6DOG+Lhz2oVC6+la+QkFiN2s10Jl/mOqxyRhoMkI2srLWOpmwwYH5o 320G5NpQBt/6WcbJz6dYrtJ9sg70ddno4ov8M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=n3JknVicXdOqirOfLAkYPJr8Z0EARLSp7OZQrxzeiJXlfvajfYV84L1X/ThHtb4jNV DExrBZv0a5V5p8kmeFL+/LnhwFRg0EM2bcQBdFu2h7ErzEwA6vqF3CEmkctT37zmeonL 7dZGhugISCJ1ozi/WEH+8APUCIzkUpEAaNpjo= Received: by 10.223.117.20 with SMTP id o20mr3891834faq.55.1279551889700; Mon, 19 Jul 2010 08:04:49 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id b36sm2049774faq.11.2010.07.19.08.04.48 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 08:04:48 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C44694C.9040108@FreeBSD.org> Date: Mon, 19 Jul 2010 18:03:40 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Marius Strobl 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> In-Reply-To: <20100719122423.GA4706@alchemy.franken.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-sparc64@FreeBSD.org Subject: Re: [RFC] Event timers on sparc64/sun4v X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 15:04:51 -0000 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