From owner-freebsd-mips@FreeBSD.ORG Tue Jul 27 14:43:32 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 C05451065673; Tue, 27 Jul 2010 14:43:32 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1C4188FC15; Tue, 27 Jul 2010 14:43:31 +0000 (UTC) Received: by vws7 with SMTP id 7so4356150vws.13 for ; Tue, 27 Jul 2010 07:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=qF2ZIuysJvnJRKyDicd0BdfFC3VXaP7U6u5djvCF68M=; b=FbwK/Uc6XE6rZ1TaLe23chvs0n3la1LmeCy1Me9gYfhtPK1CKWWCp1sftsNOVkVcAC BCA45LdmjeJdCql2kXkhFhgxMgyGcRMeI66Sa9n4YlNaVls8gQp7/SD2kJwYWCKt1jXY OeAiVrAsAdiAuXY9ngZ8zaRCfQaqgF5zMxrTw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GUSE9osr0ToBybmXfcBOxra8V9PyjbYdw8qMR1OQk9gpPHAKsqL8qLBxjJ06PsnVmy 9CyFGOz05GPWx1CZFU2uG8xjvGhiK7yrwc7zdTlqZpILm/XXr3EJch4NYeTJVD4lZE7S FNTuszO8tlsgvxZ5wxuUs+/SRX/B6vBri0EbE= MIME-Version: 1.0 Received: by 10.220.89.68 with SMTP id d4mr5146552vcm.98.1280241810782; Tue, 27 Jul 2010 07:43:30 -0700 (PDT) Received: by 10.220.195.11 with HTTP; Tue, 27 Jul 2010 07:43:30 -0700 (PDT) In-Reply-To: <4C4ED247.80701@FreeBSD.org> References: <4C41A248.8090605@FreeBSD.org> <4C41B4CF.6080409@FreeBSD.org> <4C4205CC.6080700@FreeBSD.org> <4C4ED247.80701@FreeBSD.org> Date: Tue, 27 Jul 2010 20:13:30 +0530 Message-ID: From: "Jayachandran C." To: Alexander Motin Content-Type: multipart/mixed; boundary=0016364ed2685bb957048c5f86b6 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 14:43:32 -0000 --0016364ed2685bb957048c5f86b6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 27, 2010 at 6:04 PM, Alexander Motin wrote: > 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. =A0We also have a >>>> PIC which can provide a better timestamp and timer interrupts. =A0This >>>> PIC timestamp can be read from all CPUs but the timer interrupt can be >>>> delivered to just one CPU at a time. =A0I think this is how we ended u= p >>>> 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: >>> =A0- PIC timestamp looks like the best candidate for system timecounter= . >>> =A0- per-CPU counters could be registered as per-CPU timecounters with >>> set_cputicker() - the main criteria there is a speed. >>> =A0- 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. >>> =A0- 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. >>> =A0- if there is any other timer hardware - it also should be registere= d - >>> 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 b= ootup. >> --- >> 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 =A0can be? > > I think it can easily be result of broken tick_ticker(). I'm planning to check-in the attached patch for mips/rmi, I think mips/mips would need something similar. JC. --0016364ed2685bb957048c5f86b6 Content-Type: text/x-patch; charset=US-ASCII; name="ticker.patch" Content-Disposition: attachment; filename="ticker.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gc4uytwl0 SW5kZXg6IHN5cy9taXBzL3JtaS90aWNrLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL21pcHMvcm1pL3Rp Y2suYwkocmV2aXNpb24gMjEwNTM0KQorKysgc3lzL21pcHMvcm1pL3RpY2suYwkod29ya2luZyBj b3B5KQpAQCAtNjIsOSArNjIsOCBAQAogc3RhdGljIERQQ1BVX0RFRklORSh1aW50MzJfdCwgY3lj bGVzX3Blcl90aWNrKTsKIHN0YXRpYyB1aW50MzJfdCBjeWNsZXNfcGVyX3VzZWM7CiAKLXN0YXRp YyB1X2ludDMyX3QgY291bnRlcl91cHBlciA9IDA7Ci1zdGF0aWMgdV9pbnQzMl90IGNvdW50ZXJf bG93ZXJfbGFzdCA9IDA7Ci0KK3N0YXRpYyBEUENQVV9ERUZJTkUodWludDMyX3QsIGNvdW50ZXJf dXBwZXIpOworc3RhdGljIERQQ1BVX0RFRklORSh1aW50MzJfdCwgY291bnRlcl9sb3dlcl9sYXN0 KTsKIHN0YXRpYyBEUENQVV9ERUZJTkUodWludDMyX3QsIGNvbXBhcmVfdGlja3MpOwogc3RhdGlj IERQQ1BVX0RFRklORSh1aW50MzJfdCwgbG9zdF90aWNrcyk7CiAKQEAgLTEwNiw2ICsxMDUsNyBA QAogewogCXVpbnQ2NF90IHJldDsKIAl1aW50MzJfdCB0aWNrdG9jazsKKwl1aW50MzJfdCB0X2xv d2VyX2xhc3QsIHRfdXBwZXI7CiAKIAkvKgogCSAqIFhYWDogTUlQUzY0IHBsYXRmb3JtcyBjYW4g cmVhZCA2NC1iaXRzIG9mIGNvdW50ZXIgZGlyZWN0bHkuCkBAIC0xMTUsMTIgKzExNSwxNiBAQAog CSAqLwogCXRpY2t0b2NrID0gbWlwc19yZF9jb3VudCgpOwogCWNyaXRpY2FsX2VudGVyKCk7Ci0J aWYgKHRpY2t0b2NrIDwgY291bnRlcl9sb3dlcl9sYXN0KQotCQljb3VudGVyX3VwcGVyKys7Ci0J Y291bnRlcl9sb3dlcl9sYXN0ID0gdGlja3RvY2s7CisJdF9sb3dlcl9sYXN0ID0gRFBDUFVfR0VU KGNvdW50ZXJfbG93ZXJfbGFzdCk7CisJdF91cHBlciA9IERQQ1BVX0dFVChjb3VudGVyX3VwcGVy KTsKKwlpZiAodGlja3RvY2sgPCB0X2xvd2VyX2xhc3QpCisJCXRfdXBwZXIrKzsKKwl0X2xvd2Vy X2xhc3QgPSB0aWNrdG9jazsKIAljcml0aWNhbF9leGl0KCk7CiAKLQlyZXQgPSAoKHVpbnQ2NF90 KSBjb3VudGVyX3VwcGVyIDw8IDMyKSB8IGNvdW50ZXJfbG93ZXJfbGFzdDsKKwlEUENQVV9TRVQo Y291bnRlcl91cHBlciwgdF91cHBlcik7CisJRFBDUFVfU0VUKGNvdW50ZXJfbG93ZXJfbGFzdCwg dF9sb3dlcl9sYXN0KTsKKwlyZXQgPSAoKHVpbnQ2NF90KXRfdXBwZXIgPDwgMzIpIHwgdF9sb3dl cl9sYXN0OwogCXJldHVybiAocmV0KTsKIH0KIApAQCAtMjY1LDkgKzI2OSw5IEBACiAJCW1pcHNf d3JfY29tcGFyZSgweGZmZmZmZmZmKTsKIAogCWNyaXRpY2FsX2VudGVyKCk7Ci0JaWYgKGNvdW50 IDwgY291bnRlcl9sb3dlcl9sYXN0KSB7Ci0JCWNvdW50ZXJfdXBwZXIrKzsKLQkJY291bnRlcl9s b3dlcl9sYXN0ID0gY291bnQ7CisJaWYgKGNvdW50IDwgRFBDUFVfR0VUKGNvdW50ZXJfbG93ZXJf bGFzdCkpIHsKKwkJRFBDUFVfU0VUKGNvdW50ZXJfdXBwZXIsIERQQ1BVX0dFVChjb3VudGVyX3Vw cGVyKSArIDEpOworCQlEUENQVV9TRVQoY291bnRlcl9sb3dlcl9sYXN0LCBjb3VudCk7CiAJfQog CiAJaWYgKGN5Y2xlc19wZXJfdGljayA+IDApIHsK --0016364ed2685bb957048c5f86b6--