From owner-freebsd-current@freebsd.org Wed Jan 18 01:20:54 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E51CACB49DD for ; Wed, 18 Jan 2017 01:20:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B618C1374; Wed, 18 Jan 2017 01:20:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 45C5410A7B9; Tue, 17 Jan 2017 20:20:53 -0500 (EST) From: John Baldwin To: Hans Petter Selasky Cc: Ian Lepore , FreeBSD Current , Konstantin Belousov Subject: Re: Strange issue after early AP startup Date: Tue, 17 Jan 2017 17:18:25 -0800 Message-ID: <3558195.Ack1AKBXSB@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: <11f27a15-f9bc-8988-a17e-78aeff1745fb@selasky.org> References: <1484682389.86335.166.camel@freebsd.org> <11f27a15-f9bc-8988-a17e-78aeff1745fb@selasky.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Tue, 17 Jan 2017 20:20:53 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 01:20:55 -0000 On Tuesday, January 17, 2017 10:28:47 PM Hans Petter Selasky wrote: > On 01/17/17 20:46, Ian Lepore wrote: > >>> Does this matter for the first tick? How often is configtimer() called? > >> > > >> > As I said, it is called at runtime when profclock is started / stopped, not > >> > just at boot. Those changes at runtime probably have existing callouts > >> > active and your change will not process any callouts until the next hardclock > >> > tick fires (but only because you are setting nextcallopt to the bogus > >> > 'next' value). > > On some platforms, configtimer() can be called quite often. Power > > saving modes can change the frequency of the timer, and systems that > > suppport such dynamic frequency scaling call configtimer() > > (via cpu_et_frequency()) to handle the changes. > > Hi, > > I propose the following patch then: > > diff --git a/sys/kern/kern_clocksource.c b/sys/kern/kern_clocksource.c > index 7f7769d..5ae925b 100644 > --- a/sys/kern/kern_clocksource.c > +++ b/sys/kern/kern_clocksource.c > @@ -511,8 +511,13 @@ configtimer(int start) > state->nexthard = next; > state->nextstat = next; > state->nextprof = next; > - state->nextcall = next; > - state->nextcallopt = next; > + /* > + * Force callout_process() to be called > + * instantly, so that the correct value of > + * "nextcall" can be computed: > + */ > + state->nextcall = SBT_MAX; > + state->nextcallopt = now + 1; > hardclock_sync(cpu); > } > busy = 0; > > > Then there is no problem having to wait for the next tick or anything, > like John Baldwin pointed out. Note that 'nextevent' remains a full 'timerperiod' out (now + timerperiod) and so the first clock interrupt is still 'timerperiod' time away and any callouts are delayed by that amount of time. Also, I think you could set nextcallopt to 'now' rather than 'now + 1'. You might still want to adjust 'nextevent' to schedule the next interrupt to be sooner than 'timerperiod' though. You could just set 'nextevent' to 'now' in that case instead of 'next'. -- John Baldwin