Page MenuHomeFreeBSD

tcp: Make hostcache.cache_count MPSAFE by using a counter_u64_t
ClosedPublic

Authored by rscheff on Mar 31 2021, 10:53 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Jun 24, 7:50 PM
Unknown Object (File)
Jun 13 2024, 6:26 AM
Unknown Object (File)
May 29 2024, 9:07 PM
Unknown Object (File)
May 23 2024, 6:34 AM
Unknown Object (File)
May 20 2024, 10:06 PM
Unknown Object (File)
May 18 2024, 7:04 AM
Unknown Object (File)
May 2 2024, 10:04 PM
Unknown Object (File)
Apr 24 2024, 7:49 PM
Subscribers

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 38209
Build 35098: arc lint + arc unit

Event Timeline

This revision is now accepted and ready to land.Mar 31 2021, 1:59 PM

FWIW, I disagree with this change. I think we should instead use atomic operations here.

Counters have the property that they are cheap to update, but expensive to read. Moreover, if you are doing a lot of reads, you will be pulling in cachelines from the per-CPU space into other CPUs (which is fine, but uses cache space).

For something which will be written often, but only read occasionally, counters are a big performance win. (Statistics, for example, are a great example of things for which counters are ideal.) For things which are read with any regularity (and, especially, from critical paths), atomics should perform better.

I suggest reverting this change and replacing it with atomic operations.

In D29510#661680, @jtl wrote:

FWIW, I disagree with this change. I think we should instead use atomic operations here.

Counters have the property that they are cheap to update, but expensive to read. Moreover, if you are doing a lot of reads, you will be pulling in cachelines from the per-CPU space into other CPUs (which is fine, but uses cache space).

For something which will be written often, but only read occasionally, counters are a big performance win. (Statistics, for example, are a great example of things for which counters are ideal.) For things which are read with any regularity (and, especially, from critical paths), atomics should perform better.

I suggest reverting this change and replacing it with atomic operations.

Thanks for the explanation. I actually suggested to Richard to use the counter API instead of atomic operations. So it is my mistake...