From owner-freebsd-current@freebsd.org Tue Jan 17 19:47:39 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 54519CB4AA6 for ; Tue, 17 Jan 2017 19:47:39 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 32A1B1D0F for ; Tue, 17 Jan 2017 19:47:38 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 946b6887-dced-11e6-acc0-c7e6c9ad01d6 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 946b6887-dced-11e6-acc0-c7e6c9ad01d6; Tue, 17 Jan 2017 19:46:04 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v0HJkTFv018152; Tue, 17 Jan 2017 12:46:29 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1484682389.86335.166.camel@freebsd.org> Subject: Re: Strange issue after early AP startup From: Ian Lepore To: John Baldwin , Hans Petter Selasky Cc: FreeBSD Current , Konstantin Belousov Date: Tue, 17 Jan 2017 12:46:29 -0700 In-Reply-To: <4212167.Wq8tLU1ohU@ralph.baldwin.cx> References: <2215603.KuBd8pM5Pm@ralph.baldwin.cx> <3cbe6454-82cc-0592-4ee6-3c1552b19f9a@selasky.org> <4212167.Wq8tLU1ohU@ralph.baldwin.cx> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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: Tue, 17 Jan 2017 19:47:39 -0000 On Tue, 2017-01-17 at 11:00 -0800, John Baldwin wrote: > >  > You could > >  > do that by setting it to 'cc_firstevent' of the associated CPU, but in > >  > practice 'state->nextcall' should already be set to that (it is  > > initalized > >  > to SBT_MAX in cpu_initclocks_bsp() and is then only set to other  > > values due > >  > to cpu_new_callout()).  Keep in mind that configtimer() is not just  > > called > >  > from boot, but is also invoked when starting/stopping the profiling  > > timer. > >  > > >  > >  > However, when setting 'nextevent' (which is used to schedule the next  > > timer > >  > interrupt), we should be honoring the existing 'nextcall' if it is sooner > >  > than the next hardclock. > >  > > 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. -- Ian