Page MenuHomeFreeBSD

crypto: hide crypto_destroyreq behind a tunable
ClosedPublic

Authored by mjg on Sep 23 2021, 7:22 PM.
Tags
None
Referenced Files
F84525449: D32084.id95578.diff
Sat, May 25, 1:25 AM
Unknown Object (File)
Wed, May 22, 5:03 AM
Unknown Object (File)
Wed, May 22, 5:03 AM
Unknown Object (File)
Wed, May 22, 4:53 AM
Unknown Object (File)
Sat, May 18, 11:48 AM
Unknown Object (File)
Sat, May 18, 10:26 AM
Unknown Object (File)
Apr 17 2024, 1:38 PM
Unknown Object (File)
Mar 14 2024, 12:27 PM
Subscribers

Details

Summary

Checks there can be prohibitively expensive, for example when using ipsec one can get 90% packet loss while trying to push 2 Mbit/s, all while CPUs are executing this function.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

mjg requested review of this revision.Sep 23 2021, 7:22 PM
mjg created this revision.
jhb added a reviewer: markj.

I guess this is ok, but using DIAGNOSTIC and expecting performance seems counter-intuitive. My understanding is that DIAGNOSTIC is only for expensive checks when debugging an issue and not something to use normally (certainly not in a production environment).

This revision is now accepted and ready to land.Jan 20 2022, 7:31 PM

While DIAGNOSTIC is supposed to be for heavyweight checks, it's hard to find the right balance. There are some checks that are simply too expensive to enable outside of targeted debugging. We disable vmem_check() by default with DIAGNOSTIC, and we don't do full vm_map validation (enable_vmmap_check) even with DIAGNOSTIC enabled. In general these O(n) scans just make the system unusable. Things like the check in vm_page_free_prep() are more reasonable.

This revision was automatically updated to reflect the committed changes.