Page MenuHomeFreeBSD

only lock row in pf purge thread when work to do

Authored by jmg on Sep 9 2018, 4:52 PM.



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

rS FreeBSD src repository
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

jmg created this revision.Sep 9 2018, 4:52 PM
jmg added a comment.Sep 9 2018, 4:54 PM

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.

jmg added a comment.Sep 9 2018, 7:35 PM

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%

kp accepted this revision.Sep 10 2018, 8:51 AM
This revision is now accepted and ready to land.Sep 10 2018, 8:51 AM
jmg added a comment.Sep 10 2018, 5:18 PM

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.