Re: UVM behavior under memory pressure

This reminds me of a major cleanup Andrew Doran did in -current. PR kern/54209: NetBSD 8 large memory performance extremely low PR kern/54210: NetBSD-8 processes presumably not exiting PR kern/54727: writing a large file causes unreasonable system behaviour The logic in -current has dramatica

Re: uuidgen(2)

uuigen used to generate the version 1 variant (i adjusted the to the full 100ns resolution when porting the timecounters). Some time later somebody changed uuidgen(2) to return version 4 UUIDs I believe for simplicity and performance if I remember the commit comment correctly. I cannot tell whic

bug help needed

open Class: sw-bug Originator: Frank Kardel Release:NetBSD 8.0_STABLE Arrival-Date: Thu May 16 14:40:00 + 2019 kern/54210 [serious/high]: <http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=54210> NetBSD-8 processes presumably not exiting &

Re: struct ifnet locking [was Re: IFEF_MPSAFE]

Hi, does this panic (with -current/amd64 as of 20171221) ring a bell with anyone? shortly after starting mrouted and ntpd: panic: kernel diagnostic assertion "IFNET_LOCKED(ifp)" failed: file "/src/NetBSD/cur/src/sys/net/if.c", line 3602 fatal breakpoint trap in supervisor mode trap type 1 c

Re: nanosleep() for shorter than schedule slice

Hi ! I am pretty skeptical by the hardwired constant of 20 (clockticks). At the usual/common clock interrupt rate of 100 Hz this is 200ms. So any nanosleep below 200ms will be a kernel busy loop... For sleeps less than 1 (at most two) clock ticks this would be a crude workaround until we ha

Re: Understanding PR kern/43997 (kernel timing problems / qemu)

Hi Andreas ! On 07/30/17 15:20, Andreas Gustafsson wrote: > Frank Kardel wrote: >> Could you check which timecounter is used under qemu? >> >> sysctl kern.timecounter.hardware > > # sysctl kern.timecounter.hardware > kern.timecounter.hardware = hpet0 > >>

Re: Understanding PR kern/43997 (kernel timing problems / qemu)

Could you check which timecounter is used under qemu? sysctl kern.timecounter.hardware Usually the timecounters are hardware-based and have no relation to the clockinterrupt. In case of qemu you might get a good emulated timecounter, but a suboptimal clockinterupt. If this is the case it helps t

Re: nanosleep() for shorted than schedule slice

On 07/03/17 07:25, Michael van Elst wrote: b...@softjar.se (Johnny Billquist) writes: Having the normal wall clock driven by a tick interrupt has its points. We usually avoid this and use what hardware timer the platform offers. Basically yes, but as these timers wrap after a while we need

Re: On softints, softnet_lock and sleeping (aka ipv6 vs USB network interfaces)

Hi ! Is there any progress on this? I see also PR/49065 being still existent on an RPI2. Also running named with 4 threads on an RPI2 together with vtund doing "ifconfig tunX ..." is a sure killer. Runinng named with only one thread gets you over it (maybe just most of the time). Softnet-loc

Re: specific platform check in driver match routine

On 06/10/13 12:12, Martin Husemann wrote: On Mon, Jun 10, 2013 at 11:51:27AM +0200, Frank Kardel wrote: platform. E.g. isa bus based GPIO registers there are present on a Soekris net6501 only. Often in such cases the pci bridges have specific PCI IDs that can be used to positively identify the

specific platform check in driver match routine

Hi driver-wranglers, is there a good way that a match routine can verify it is a running on a certain platform. E.g. isa bus based GPIO registers there are present on a Soekris net6501 only. From dmesg I have only seen that MPBIOS can find the vendor and device information. Do we collect and B