Page MenuHomeFreeBSD

only lock row in pf purge thread when work to do
ClosedPublic

Authored by jmg on Sep 9 2018, 4:52 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Dec 21, 2:35 AM
Unknown Object (File)
Tue, Dec 10, 6:59 PM
Unknown Object (File)
Nov 23 2024, 4:04 AM
Unknown Object (File)
Nov 11 2024, 6:37 PM
Unknown Object (File)
Oct 20 2024, 9:47 AM
Unknown Object (File)
Oct 14 2024, 9:47 PM
Unknown Object (File)
Sep 28 2024, 3:51 PM
Unknown Object (File)
Sep 28 2024, 9:08 AM

Details

Summary

Only take a lock when we know that there is work to do.
When expiring states, we currently always take a lock, even when
the list is empty. We can check to see if the list is empty and
if it is, do not take a lock.

This is fine, as we'll check again in 10 seconds, and even if we
lost a race, it doesn't make sense for the state to immediately
time out.

On my Pine A64-LTS arm64 board, it dropped CPU usage of the pf
purge thread from 1.2% down to .28% CPU usage. This is on a system
where only kldload pf was done, and with out any rules loaded...
I'll be added additional testing from an active router...

This was inspired by the increase in cpu usage due to the recent
increase in hashsize.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

note, if you apply the diff and check it w/ svn diff -x -wb, you'll see that the only change is the comment, the if, and the braces.

CPU usage calculated by taking the time pf purge ran and dividing it by the difference between now, and lstart:

ps -ax -o lstart,time,command | grep pf; date

Sun Sep 9 16:31:23 2018 0:30.95 [pf purge]
Sun Sep 9 19:33:53 2018 0:00.02 grep pf
Sun Sep 9 19:33:53 UTC 2018

30.95 / (30+2*60+3*60*60) == .283%

This revision is now accepted and ready to land.Sep 10 2018, 8:51 AM

For reference, on an active pf firewall, before the patch, ~1.56% cpu core was used on the purge thread, after the patch, .427% cpu core. over a third less CPU. This is with the same 128k hash table size.

This revision was automatically updated to reflect the committed changes.