https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242427
--- Comment #6 from Peter Eriksson ---
(In reply to Konstantin Belousov from comment #5)
Yes, you are correct (and I was wrong). Sorry about that.
I've rewritten the timing tests now to use nanouptime() instead, and now things
look sligh
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242427
--- Comment #5 from Konstantin Belousov ---
I am sure that you are detecting the edge of second and not the actual sleeping
place. It probably something that happens once in second (some callout) which
allows the system to make the progres
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242427
--- Comment #4 from Peter Eriksson ---
(In reply to Peter Eriksson from comment #3)
Before someone asks - yes, in theory since I'm using the "if
(time_second-t0>0)" check, then it _could_ be just coincidence and that the
clock steps 1s jus
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242427
--- Comment #3 from Peter Eriksson ---
(In reply to Mark Johnston from comment #1)
# sysctl vm.pmap
vm.pmap.pdpe.demotions: 3
vm.pmap.pde.promotions: 18422
vm.pmap.pde.p_failures: 1050
vm.pmap.pde.mappings: 11065
vm.pmap.pde.demotions: 154
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242427
--- Comment #2 from Konstantin Belousov ---
(In reply to Mark Johnston from comment #1)
This is 11.3, right ? How any CPUs do you have ?
How do you measure that pmap_remove() takes 1sec ?
Please recompile with INVARIANTS at least and see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242427
Mark Johnston changed:
What|Removed |Added
CC||ma...@freebsd.org
--- Comment #1 f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242427
Bug ID: 242427
Summary: pmap_remove() sometimes is very slow causing 10+
minutes long reboots
Product: Base System
Version: 11.3-RELEASE
Hardware: amd64
