Date: Wed, 18 Jan 2017 08:59:33 +0100 From: Hans Petter Selasky <hps@selasky.org> To: John Baldwin <jhb@freebsd.org> Cc: Ian Lepore <ian@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, Konstantin Belousov <kib@freebsd.org> Subject: Re: Strange issue after early AP startup Message-ID: <5a6f8c14-3f9c-e51e-4285-5d4ba7a365b9@selasky.org> In-Reply-To: <3558195.Ack1AKBXSB@ralph.baldwin.cx> References: <b9c53237-4b1a-a140-f692-bf5837060b18@selasky.org> <1484682389.86335.166.camel@freebsd.org> <11f27a15-f9bc-8988-a17e-78aeff1745fb@selasky.org> <3558195.Ack1AKBXSB@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/18/17 02:18, John Baldwin wrote: > 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'. Hi, Does that mean the following piece of code is missing from getnextevent(): > /* Handle callout events. */ > if (event > state->nextcall) > event = state->nextcall; Like getnextcpuevent() is doing? --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5a6f8c14-3f9c-e51e-4285-5d4ba7a365b9>