Štěpán Němec <[email protected]> wrote: > > I apologize for the late response.
No worries, I still have mails in other places from months ago I've been meaning to get to :x > On Mon, 23 Oct 2023 19:58:18 +0000 > Eric Wong wrote: > > > Thanks for the info. Just curious, what HW specs (ncpus, RAM) > > is available on that system? I wonder if that affects timing > > somehow... > > dmesg: > https://dmesgd.nycbug.org/index.cgi?do=view&id=7357 > ncpus = 2 (so it's running the MP (multiprocessor) kernel), 1GB RAM Alright, will keep that in mind. OpenBSD doesn't seem to benefit from having many cores and I stress out about the test suite taking ~30s on my fastest HW. > > Unfortunately, my *BSD debugging knowledge is far behind my > > Linux; so I'm not sure how much help it'd be... > > If nothing else, you could do some tests on an otherwise > idle machine with good Internet connectivity (unless the > connection issues you keep mentioning are mainly on your > end, that is). Yeah, it's mainly on my end, but seems improved in the past 2 weeks or so. > > Some examples of things I miss on OpenBSD: > > > > * /proc/$PID/fdinfo/$FD_OF_EPOLL on Linux is immensely helpful > > for knowing what and how epoll is watching target FDs. I'm > > not sure if there's a way to introspect kqueue like that > > Yeah, most likely there isn't, though I'm not quite sure > what exactly "like that" entails. Care to expand a bit upon > the immense usefulness mentioned, i.e., how this helps you > specifically? Knowing which EVFILT_* and EV_* flags are in use for a given target FD would be useful (analogous to the single events: field printed in /proc/$pid/fdinfo/$epfd that corresponds to struct epoll_event.events) > OpenBSD fstat(1) prints the kqueue memory addresses, so I > suppose a sufficiently determined individual could get > arbitrary info from the running kernel based on that, > although at that point there are probably better ways to get > the address than running fstat... I'll have to remember that next time I need to and RTFM for it. I didn't know about the fstat(1) command until a few weeks ago (horrible naming conflict with the fstat(2) syscall didn't help with discovery) <snip> I'll keep the rest in mind next time I need it. > > * Linux strace decodes more struct args info than kdump > > strace is certainly more featureful, though in the specific > case of kqueue/kevent I think kdump does show everything one > would expect to see? Ah, I think I was going off my FreeBSD experience, there; OpenBSD does seem to decode sendmsg/recvmsg args well. FreeBSD doesn't tell me which FDs are being sent/received via SCM_RIGHTS, maybe that's improved in FreeBSD 14... But yeah, still lots of work to do elsewhere; but OpenBSD seems like an important driver in keeping Perl5 stable and widely-installed. *BSDs in general have been great at finding bugs that might eventually impact my GNU/Linux systems.
