On 01/23/17 06:27, Jia-Shiun Li wrote:
On Sat, Jan 21, 2017 at 3:51 PM, Hans Petter Selasky
wrote:
FYI:
https://svnweb.freebsd.org/changeset/base/312551
Hi hps,
sorry I have to correct my test results.
I found that I did not revert changes to kernel config,
which commented out EARLY_AP_ST
On Sat, Jan 21, 2017 at 3:51 PM, Hans Petter Selasky
wrote:
> FYI:
>
> https://svnweb.freebsd.org/changeset/base/312551
>
>
Hi hps,
sorry I have to correct my test results.
I found that I did not revert changes to kernel config,
which commented out EARLY_AP_STARTUP option,
before testing you pat
FYI:
https://svnweb.freebsd.org/changeset/base/312551
--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On Thu, Jan 19, 2017 at 4:23 PM, Hans Petter Selasky
wrote:
>
> I can add prints/asserts to show that what happens is that
> "state->nextcallopt > now" while "state->nextcall <= now". This situtation
> is allowed to persist due to the way getnextcpuevent() is currently
> implemented.
>
> Can the
On 01/18/17 09:00, Hans Petter Selasky wrote:
On 01/18/17 02:18, John Baldwin wrote:
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'.
Right, I'll give that
In message <1922021.4hjeqfj...@ralph.baldwin.cx>, John Baldwin writes:
> On Tuesday, January 17, 2017 05:08:58 PM Cy Schubert wrote:
> > In message <1492450.xzfnz8z...@ralph.baldwin.cx>, John Baldwin writes:
> > > On Tuesday, January 17, 2017 12:53:19 PM Cy Schubert wrote:
> > > > In message , Hans
On Wednesday, January 18, 2017 09:00:52 AM Hans Petter Selasky wrote:
> On 01/18/17 02:18, John Baldwin wrote:
> > 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
On 01/18/17 02:18, John Baldwin wrote:
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'.
Right, I'll give that a spin. Would have to be "now + 1" instead of
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 'n
Hi,
On 01/18/17 02:18, John Baldwin wrote:
Also, I think you could
set nextcallopt to 'now' rather than 'now + 1'.
There is a check in loadtimer() if next == now, and then the event timer
is not started ??
} else {
new = getnextevent();
eq = (new ==
On Tuesday, January 17, 2017 05:08:58 PM Cy Schubert wrote:
> In message <1492450.xzfnz8z...@ralph.baldwin.cx>, John Baldwin writes:
> > On Tuesday, January 17, 2017 12:53:19 PM Cy Schubert wrote:
> > > In message , Hans
> > > Petter
> > > Sela
> > > sky writes:
> > > > Hi,
> > > >
> > > > When
On Tuesday, January 17, 2017 10:35:06 PM Hans Petter Selasky wrote:
> On 01/17/17 22:28, Hans Petter Selasky wrote:
> > + state->nextcall = SBT_MAX;
> > + state->nextcallopt = now + 1;
>
> BTW: What locks are protecting the update of these fields? Can th
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 b
In message <1492450.xzfnz8z...@ralph.baldwin.cx>, John Baldwin writes:
> On Tuesday, January 17, 2017 12:53:19 PM Cy Schubert wrote:
> > In message , Hans Petter
> > Sela
> > sky writes:
> > > Hi,
> > >
> > > When booting I observe an additional 30-second delay after this print:
> > >
> > > > Ti
On Tuesday, January 17, 2017 12:53:19 PM Cy Schubert wrote:
> In message , Hans Petter
> Sela
> sky writes:
> > Hi,
> >
> > When booting I observe an additional 30-second delay after this print:
> >
> > > Timecounters tick every 1.000 msec
> >
> > ~30 second delay and boot continues like normal
On Tuesday, January 17, 2017 08:31:28 PM Hans Petter Selasky wrote:
> Hi,
>
> On 01/17/17 20:00, John Baldwin 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 boo
On 01/17/17 22:28, Hans Petter Selasky wrote:
+ state->nextcall = SBT_MAX;
+ state->nextcallopt = now + 1;
BTW: What locks are protecting the update of these fields? Can they be
written simultaneously by configtimer() and cpu_new_callout()?
--HPS
_
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
In message , Hans Petter
Sela
sky writes:
> Hi,
>
> When booting I observe an additional 30-second delay after this print:
>
> > Timecounters tick every 1.000 msec
>
> ~30 second delay and boot continues like normal.
>
> Checking "vmstat -i" reveals that some timers have been running loose.
>
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
Hi,
On 01/17/17 20:00, John Baldwin 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 no
On Tuesday, January 17, 2017 07:04:15 PM Hans Petter Selasky wrote:
> On 01/17/17 16:50, John Baldwin wrote:
> > On Monday, January 16, 2017 10:10:16 PM Hans Petter Selasky wrote:
> >> On 01/16/17 20:31, John Baldwin wrote:
> >>> On Monday, January 16, 2017 04:51:42 PM Hans Petter Selasky wrote:
On 01/17/17 16:50, John Baldwin wrote:
> On Monday, January 16, 2017 10:10:16 PM Hans Petter Selasky wrote:
>> On 01/16/17 20:31, John Baldwin wrote:
>>> On Monday, January 16, 2017 04:51:42 PM Hans Petter Selasky wrote:
Hi,
When booting I observe an additional 30-second delay after
On 01/17/17 16:50, John Baldwin wrote:
Index: kern_clocksource.c
===
--- kern_clocksource.c (revision 312301)
+++ kern_clocksource.c (working copy)
@@ -503,7 +503,12 @@ configtimer(int start)
state->
On 01/17/17 16:50, John Baldwin wrote:
(One odd thing is that even in your case the first call to handleevents(),
the 'now => state->nextcallout' check in handleevents() should be true
which resets both nextcall and nextcallopt and invokes callout_process().)
Hi,
I suspect the cpu_new_callout(
On Monday, January 16, 2017 10:10:16 PM Hans Petter Selasky wrote:
> On 01/16/17 20:31, John Baldwin wrote:
> > On Monday, January 16, 2017 04:51:42 PM Hans Petter Selasky wrote:
> >> Hi,
> >>
> >> When booting I observe an additional 30-second delay after this print:
> >>
> >>> Timecounters tick e
On 01/16/17 20:31, John Baldwin wrote:
On Monday, January 16, 2017 04:51:42 PM Hans Petter Selasky wrote:
Hi,
When booting I observe an additional 30-second delay after this print:
Timecounters tick every 1.000 msec
~30 second delay and boot continues like normal.
Checking "vmstat -i" reve
On Monday, January 16, 2017 04:51:42 PM Hans Petter Selasky wrote:
> Hi,
>
> When booting I observe an additional 30-second delay after this print:
>
> > Timecounters tick every 1.000 msec
>
> ~30 second delay and boot continues like normal.
>
> Checking "vmstat -i" reveals that some timers hav
Hi,
When booting I observe an additional 30-second delay after this print:
Timecounters tick every 1.000 msec
~30 second delay and boot continues like normal.
Checking "vmstat -i" reveals that some timers have been running loose.
cpu0:timer 44300442
cpu1:tim
29 matches
Mail list logo
