From owner-freebsd-sparc64@FreeBSD.ORG Tue Jul 20 11:11:28 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 3C7D11065677 for ; Tue, 20 Jul 2010 11:11:28 +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 BA8D18FC12 for ; Tue, 20 Jul 2010 11:11:27 +0000 (UTC) Received: by fxm13 with SMTP id 13so2960731fxm.13 for ; Tue, 20 Jul 2010 04:11:26 -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=fnwP+dkxmVAsSXGlxKMsSaVqlviV7J+MlFihGA4JgnA=; b=o4QeyEv40uc1unHB9hCxfp8hcGCo4QQ08g31/b1oDLhU3EHXuhlN1VlABi6/x4vBCf BNFv6bVqieqBhDnijkgkIS1H0woHVz2W0lew0AjwWcZpxCoqFjeVGmICau4bZWQjxqw/ RoPzSK5LYfnDdiEYVJuFLfbJT3ldnMuUziDJM= 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=xKOLMv0Txw/qVQRgfcUpAR7pvSbQjWpHbIzkIAfuvfkpIjIsQQcaisNnHVbtChK8Sl tA9Ft3ET12RDwlX8Pau6b/HEvXEonZNiq3P3roMAz/77R1SMtyaNmKYoqQ7PMM42ture XZz66Y/446Va6YJmvsLFrKafHOQiEEQ1ORuVY= Received: by 10.86.63.10 with SMTP id l10mr3863420fga.28.1279624286630; Tue, 20 Jul 2010 04:11:26 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id w11sm2412410fao.37.2010.07.20.04.11.25 (version=SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 04:11:25 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C458417.3010707@FreeBSD.org> Date: Tue, 20 Jul 2010 14:10:15 +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> <4C44694C.9040108@FreeBSD.org> <20100720105454.GE4706@alchemy.franken.de> In-Reply-To: <20100720105454.GE4706@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: Tue, 20 Jul 2010 11:11:28 -0000 Marius Strobl wrote: > On Mon, Jul 19, 2010 at 06:03:40PM +0300, Alexander Motin wrote: >> 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. > > My understanding is that the only advantage of the STICK counter > over the TICK one is that the former is always driven by the same > frequency across all CPUs in a system, regardless of the frequency > the CPUs are running at (as needed in machines equipped with > different CPU models or when down throttling). It seems like question to platform, not CPU documentation. I may assume (theoretically), that depending on chipset, CPUs may have: single bus clock generator, several asynchronous generators with same frequency (non-coherent) or event several generators with different frequencies. First case is the best, second may require periodic synchronization to avoid drift, third additionally requires some scaling. It would be nice to play with some problematic system to find are things so bad or reason is somewhere else. Unless it is documented somewhere. -- Alexander Motin