From owner-freebsd-sparc64@FreeBSD.ORG Fri Jul 16 22:03:36 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 BD089106566C for ; Fri, 16 Jul 2010 22:03:36 +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 45AE48FC1B for ; Fri, 16 Jul 2010 22:03:35 +0000 (UTC) Received: by fxm13 with SMTP id 13so1508975fxm.13 for ; Fri, 16 Jul 2010 15:03:35 -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=4cdoG4DWFdWPLgPDnaKFkuMxIW4CbNyfmPfWVNU9IpA=; b=o1IZn4Qb6EvQyIqszqdB50pXNeKnnp5dTRh6QOqlDP9ulVKRkcU+35riBzAkxF9UdI I+Qa/MH+GPJj3Ay2wAJeRMmxx+D5Voc6Pwdx4cyP4FyN34ke0WcGUSz83+WdtN6wG64g wqyd0PiJYWBy/OZgjRsHJZdXVvQ7oNcT92ZD4= 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=t1eBn+QVvVx+btlj885fak+c0omVdQIHuUh2gOFEOgvvNqrG1UucdbI1pqWpcQR4Bz Lw63qFI2n3KvaOc5eh+vyt698Sd3etqL1fTlso2Yt+lcHnDAq/NopYzigLHg4+zTKk9X CoEiDe9UJezYTlQxE/s2ISYDHuCv+ACC3IWns= Received: by 10.223.113.135 with SMTP id a7mr1177037faq.40.1279317814708; Fri, 16 Jul 2010 15:03:34 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id e16sm916217fak.42.2010.07.16.15.03.33 (version=SSLv3 cipher=RC4-MD5); Fri, 16 Jul 2010 15:03:34 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C40D6F5.6070208@FreeBSD.org> Date: Sat, 17 Jul 2010 01:02:29 +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> In-Reply-To: <20100716213503.GT4706@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: Fri, 16 Jul 2010 22:03:36 -0000 Marius Strobl wrote: > On Fri, Jul 16, 2010 at 02:18:48PM +0300, Alexander Motin wrote: >> I've made a patch, updating sparc64/sun4v timer driver to utilize new MI >> event timer infrastructure. There are several benefits: >> - unified interfaces and behavior with other platforms, >> - support for timer in one-shot mode, >> - more timer hardware can be easily supported (if there any). >> Code works for me on UP sparc64 (SunBlade 100) and builds on sun4v. >> Should work on SMP, but I can't test it. >> >> Patch for HEAD can be found here: >> http://people.freebsd.org/~mav/timers_sparc.patch >> >> Any comments? > > please don't commit this as-is: That is why I am asking. :) > - using the stick instead of the tick counter for machines with CPUs > and thus tick counters running at different speeds has turned out > to be suboptimal, probably due to the fact that the 12.5MHz the > stick counters typically are driven by don't provide sufficient > granularity. On x86 ACPI HPET timers often run about 15MHz, i8254 - about 1.2MHz. What's wrong with 12.5MHz here? > Thus the more desireable variant for these machines > probably is to provide the tick counter of the BSP as the only > non-per-CPU timer and forward it to the APs via IPIs. It would be possible if timer was programmable from any CPU. But as I understand - it require thread to be binded, which handled by infrastructure only for per-CPU timer. > This also > leaves the stick counter of all >= US-III machines generally > available for driving statclock, which likely is also desirable. It would be nice, but I don't know how separate their interrupts. > - I'd like to keep the tick grace check as this caused problems in > the past. Probably tick_et_start() just should return an error > in this case. I think it would be nice to move it to MI code. MI code knows about base frequency, so theoretically can adapt to it. May be we could fetch some additional info there, if needed. ACPI HPET timer also defines minimal reliable period, so solution could/should be common. > - I don't like wasting CPU cycles for determining whether the > workaround for BlackBird CPUs is needed (assuming #1 above is > implemented so distinguishing stick/tick is no longer needed) > with every (s)tick interrupt which are a lot as this just won't > ever change during runtime, i.e. I'd like to keep the different > interrupt handlers which are set up as needed. Does it worth code duplication? Won't it be always cached/ predicted/ prefetched? I have doubt that difference can ever be measured, as this function is minor part of things done on interrupt. > - Replacing intr_disable_all() with intr_disable() on sun4v > probably isn't a good idea as the latter doesn't disable IPIs > as it does on sparc64 and other architectures. Oops, just blind copy-paste. Thank you. -- Alexander Motin