svn commit: r357051 - head/sys/dev/bge
Gleb Smirnoff
glebius at freebsd.org
Mon Jan 27 20:43:36 UTC 2020
On Sun, Jan 26, 2020 at 09:48:42AM +0000, John Baldwin wrote:
J> > We also are concerned about that theoretically. Haven't yet seen effect
J> > in practice, but our sessions are mostly longer living. First we have the
J> > tunable to limit batching. Second, there are some ideas on how to improve
J> > the garbage collector performance if it becomes an issue.
J>
J> There are other workloads than Netflix. ;) Verisign has incredibly short-lived
J> connections with very high turnover. I think though that they have already
J> abandoned the in-tree network stack for a userland stack built on netmap. Still,
J> I think that there are probably other FreeBSD users that are probably somewhere
J> in the middle that shouldn't be ignored.
I understand that.
First, my change doesn't create extra work for the garbage collector, but it
potentially may affect its burstiness. If a machine has very high connection
turnover it already may exhibit some problems with the PCB garbage collector
on 12.0-RELEASE. Have we observed this yet?
Note that PCBs are very different to other things protected by the network
epoch: address lists, interface lists, firewall rules, etc. They are short
lived.
We got several ideas on how to deal with this potential problem:
1) The current PCB destructor does lots of things like freeing and
unrefcounting associated multicast options, credentials, etc. This
is because it was converted to epoch with a principle of minimal
diff in r335015. However, since all operations with a PCB happen
under its individual lock, we can free it differently. We can mark
it INP_FREED and do all the destruction immediately, leaving only
actual free to the garbage collector.
Once this is achieved, the garbage collection can be batched at
level of UMA. Jeff is working on that.
2) Use separate epoch for PCBs, leaving the network epoch for long
lived structures only. Don't hold the PCB epoch long.
3) Just don't use epoch for PCBs. Decompose the hash lock into per
slot hash lock.
--
Gleb Smirnoff
More information about the svn-src-head
mailing list