On 12.9.2017. 15:53, Martin Pieuchot wrote: > Diff below reduces the scope of the NET_LOCK(), this time in sysctl > path. It is interesting for multiple reasons: > > - It reduces the contention on the NET_LOCK(), which should improve > the overall latency on the system when counters are frequently > queried. Accesses to read-only operations and per-CPU counters > are no longer protected by the NET_LOCK(). > > - It allows per-CPU counters to be accessed in parallel. counters_read(9) > is now executed without holding the NET_LOCK(). > > - sysctl_mq() is now MP-safe, by serializing access using the mq's > mutex. However a dance is required to not hold a mutex around > copyin(9)/copyout(9). > > - The NET_LOCK() is now taken around all sysctl_int(), sysctl_struct() > and sysctl_int_arr(). This is not nice but it will allow people to > fix parts of the sysctl path independently. > > Note that all data structure currently protected in these sysctl paths > do not necessarily need the NET_LOCK(). Take CARP's carp_opts[] for > example. Does it need the NET_LOCK()? Is it at all the right primitive? > Well interested readers can answer with diffs and explanations to these > questions
Hi all, i'm running this and "kqueue & rwlock" diff on primary firewall with: carp, pf, pflow, pfsync, snmpd, dhcpd, dhcp sync, ipsec, remote pflog and syslog logging and it seems that everything is working nicely ...
