From owner-freebsd-mips@FreeBSD.ORG Tue Jul 27 12:35:36 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B18C61065677; Tue, 27 Jul 2010 12:35: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 1548E8FC13; Tue, 27 Jul 2010 12:35:35 +0000 (UTC) Received: by fxm13 with SMTP id 13so593612fxm.13 for ; Tue, 27 Jul 2010 05:35:34 -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=50WwlFyByheXnakUGs2H8Ib4y6ChtRlDSL1rNrSXm98=; b=qE9DtJZwuibEaXm65o2rgSQOSlRz7meTyZBw2aqYELm2GRXk6DSapMkffSUaFpD8cl asDYmgJh9IQozPPhmkbvJ/4CSCSklnwxqxi0OXzbRBzUPe3Och5+WViQGFgYS5xICmzt 1QkGZOg82smM+gPcWdQtl2LsRotSGXRNAoazA= 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=tNHPN1BcUPbSpkm84vO6dCrtwdSZi4vqPabCtnAoSI/Kyn4iLGNpoxoxtUmo3Dle6I 3BSJPNAWlj/cyS+fzXUk59Lx5Y1ajKxJ+5vY1I+2g11LXxmAJodlTdOmA7blY6a6EDFU s2wZKggV/NGLG14y84wkTH4Z7MX6BqICjgXAg= Received: by 10.223.119.136 with SMTP id z8mr7972963faq.63.1280234133696; Tue, 27 Jul 2010 05:35:33 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id b36sm1883314faq.35.2010.07.27.05.35.31 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Jul 2010 05:35:32 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C4ED247.80701@FreeBSD.org> Date: Tue, 27 Jul 2010 15:34:15 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: "Jayachandran C." References: <4C41A248.8090605@FreeBSD.org> <4C41B4CF.6080409@FreeBSD.org> <4C4205CC.6080700@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Randall Stewart , Neel Natu , freebsd-mips@freebsd.org Subject: Re: [RFC] Event timers on MIPS X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 12:35:36 -0000 Jayachandran C. wrote: > On Sun, Jul 18, 2010 at 1:04 AM, Alexander Motin wrote: >> Jayachandran C. wrote: >>> On XLR we would like to use the count/compare which is faster but less >>> accurate on all cpus - we can have upto 32 cpus now. We also have a >>> PIC which can provide a better timestamp and timer interrupts. This >>> PIC timestamp can be read from all CPUs but the timer interrupt can be >>> delivered to just one CPU at a time. I think this is how we ended up >>> with the current implementation, but any suggestions on how to improve >>> this is welcome. > > As a first step, I have copied the count /compare code from mips with > minor modifications into mips/rmi, this lets me boot up (checked in as > r210528). > > I would like to add the PIC based clock next. Thanks. >> I would prefer to not mix the things. >> >> I think: >> - PIC timestamp looks like the best candidate for system timecounter. >> - per-CPU counters could be registered as per-CPU timecounters with >> set_cputicker() - the main criteria there is a speed. >> - if per-CPU counters are synchronized between CPUs - they could be >> registered as alternative timecounter for people who wish fastest >> timecounting; if they are not - they are useless in that role. >> - both PIC timer and per-CPU comparators should be independently >> registered as eventtimers - it is better to have two of them to from >> accounting correctness PoV, and it will allow user to experiment which >> one he likes more. >> - if there is any other timer hardware - it also should be registered - >> it will give additional flexibility. > > The per-cpu count/compare counters are not synchronized on XLR. Then tick_ticker() function looks broken. counter_lower_last and counter_upper should be tracked per-CPU. Otherwise you will have huge forward jumps due to false overflows. > So your suggestion would be to add a PIC based clock which calls > tc_init() and et_register(), and to leave the set_cputicker() to be > the count/compare? Yes. And I would leave count/compare also calling tc_init() and et_register() as it is now. It won't hurt. > Also, with just the count/compare, I get these print on early mutiuser bootup. > --- > calcru: runtime went backwards from 85936878 usec to 236488 usec for > pid 1286 (rpcbind) > calcru: runtime went backwards from 7158742 usec to 19700 usec for pid > 1285 (nfsiod 0) > calcru: runtime went backwards from 111005442 usec to 305474 usec for > pid 1257 (syslogd) > calcru: runtime went backwards from 10740196 usec to 29555 usec for > pid 1048 (devd) > -- > Did not get much time to investigate, any idea what the cause can be? I think it can easily be result of broken tick_ticker(). -- Alexander Motin