On 2021/07/02 13:09, Martin Pieuchot wrote: > On 01/07/21(Thu) 13:53, Anindya Mukherjee wrote: > > Hi, > > > > I noticed that if I leave the system running for more than about a month, > > some > > of the counters in the uvm view of systat(1) overflow and become negative. > > This > > is because the members of struct uvmexp in sys/uvm/uvmexp.h are ints. The > > kernel's internal counters are of course uint64_t so they don't overflow. It > > only happens during the uvm_sysctl(9) call which casts the numbers to > > integers. > > The function is uvmexp_read. > > > > In the attached diff I took the path of least resistance and promoted some > > of > > the counters to unsigned int. Ideally I would have liked to use int64_t or > > even > > uint64_t, but I hit an issue in some of the architecture dependent code. An > > example is: > > /usr/src/sys/arch/alpha/alpha/trap.c:536 atomic_add_int(&uvmexp.syscalls, > > 1); > > In other places the ++ operator is used to increment the counters and the > > 64 bit > > types can be used. > > > > I am not completely sure this is the best way to proceed, but even if this > > diff > > is horrifying, I'd appreciate some feedback and advice, thanks! > > I wonder if we shouldn't use uint64_t for those and embrace the ABI > break, that would at least simplify the kernel side and remove a > truncation. > > Do you have an idea of the different consumers of the "struct uvmexp" > apart from systat(1)? What is the impact in userland & ports of such > change?
It's used by a couple of dozen ports, from a search over 1-year-old ports source: lcdproc libuv, embedded copies (incl electron, node, ruby-passenger) py-uv py-psutil, embedded copies (incl spidermonkey + firefox ports) libstatgrab, embedded copies (digikam) jdk libgtop2 py-gevent net-snmp zabbix plan9port conky bubblemon-dockapp facter gkrellm free htop monit node_exporter p5-Sys-MemInfo slant tmux-mem-cpu-load xuvmstat xfce4-systemload xfce4-taskmanager Most of these would just need a recompile, so would either need a REVISION bump in the port, or in most cases bumping libc would be enough to trigger pkg_add -u to update them (some exceptions e.g. py-psutil, py-uv, py-gevent don't depend on libc and would need to be bumped separately). Go has its own translated copy of structs from system headers (e.g. in golang.org/x/sys/unix/zsysctl_openbsd_*) and these are bundled in many ports that use go (even core system libraries are not exempt from "vendoring" or having old versions used by software using modules). Obviously uvmexp isn't used in all of the software which includes these files though. Some of those ports include gopsutil which increases the chance things from struct uvmexp might actually be used (including sqlc, keybase, vault, consul, nomad, packer). Some other go ports are either very likely to use uvmexp things e.g. at least some of the sysutils/beats/XXX ports. (And I listed node_exporter in the main list above as it's almost certain).
