From owner-freebsd-sparc64@FreeBSD.ORG Wed Jul 28 07:26:49 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 E2B8F106566B for ; Wed, 28 Jul 2010 07:26:49 +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 681D78FC15 for ; Wed, 28 Jul 2010 07:26:49 +0000 (UTC) Received: by fxm13 with SMTP id 13so1076367fxm.13 for ; Wed, 28 Jul 2010 00:26:48 -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=tgQ9tGvN+Q8/x0++2fHw6jtluwJRtWl0aipBAcZRwow=; b=k7hoZuztTc6rKrSWCMd+E88ELNQxPESrksEsyXODlhzfR9CYn4gOT/FN2Tf2Pnp2W4 CMwy70AXpLDDJcOlE58hHBuqJ/rDnHbXuOjrhKE01JS2XagCNFzUvgiBkONJyzRB9WMp HC+3n8kFxBAy0qEgZUA7ac59KKjcM1kZSS8fY= 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=kz5s4G1t5P5DpwhjNWm8BJTGcWCb5CU9ydcWj0amAFknUiKk58uB5XyD0SlZlsvEQ1 ROnfYWcN4gbDm7IRjBkE42/LuNz63nwWncrYa0O1c/VvIAu5XExnLmZOvQSuF2M27/Py Zn7+c/nbKYO33+C998hR+x/MIgEZGee+9flBI= Received: by 10.223.108.66 with SMTP id e2mr9318979fap.39.1280302007059; Wed, 28 Jul 2010 00:26:47 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id w11sm2443557fao.37.2010.07.28.00.26.45 (version=SSLv3 cipher=RC4-MD5); Wed, 28 Jul 2010 00:26:46 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C4FDBB2.5000503@FreeBSD.org> Date: Wed, 28 Jul 2010 10:26:42 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) 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> <4C46E3BB.7060204@FreeBSD.org> <20100728070919.GB75632@alchemy.franken.de> In-Reply-To: <20100728070919.GB75632@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: Wed, 28 Jul 2010 07:26:50 -0000 Marius Strobl wrote: > On Wed, Jul 21, 2010 at 03:10:35PM +0300, Alexander Motin wrote: >> Here is updated patch for latest HEAD, which should handle this: >> http://people.freebsd.org/~mav/timers_sparc4.patch >> >> I also added support for STICK timecounter. For this moment with lowest >> priority to not use it by default, until it is tested. > > The patch looks ok and seems to work as expected on MP US-IIIi. > However, I'd suggest to just use TICK_QUALITY_{M,U}P for the > quality of the STICK timecounter but negated for now; I see no > reason why the STICK timecounter should be of any other quality > (from the hardware point of view) than the TICK one and whatever > the solution is to make the TICK timecounter work with locks etc > also needs to be applied to the STICK one (maybe on some machines > the synchronicity across CPUs actually happens to be sufficient > but I'd like to rather not make any assumptions about machines > that f.e. group CPUs by coherency domain etc). As you said before, STICK has lower resolution then TICK (though not so much), so I would set it's quality a bit lower. And it has more chances to work synchronously then TICK on MP, so I would set it's quality higher there. I don't actually see the reason for using negative qualities, unless timers are really broken. In such case if there will be no other timers, system will fall back to the dummy, which I have doubts is better then anything else. > A difference in behavior I noticed is that the TICK interrupt > rate now is 2kHz (with HZ 1000). Why is that (I think that on > x86 the timers ran at 2*HZ before though)? Originally it was x86 behavior for cases when only one timer available. It was made to slightly separate hardclock and statclock events for better accounting. I've just reimplemented it in more general way in new timer infrastructure. It may obsolete later when we start using timers in one-shot mode it. If you wish, you may disable it now by setting kern.eventtimer.singlemul=1. Another way is to add support for STICK event timer. When two timers available, multiplication won't be used. If you start profiling, frequency should automatically rise to about 8KHz. -- Alexander Motin