Page MenuHomeFreeBSD

crypto: hide crypto_destroyreq behind a tunable
ClosedPublic

Authored by mjg on Sep 23 2021, 7:22 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Dec 20, 2:43 PM
Unknown Object (File)
Wed, Dec 11, 1:27 AM
Unknown Object (File)
Wed, Dec 4, 5:26 PM
Unknown Object (File)
Wed, Nov 27, 11:01 PM
Unknown Object (File)
Nov 13 2024, 8:39 AM
Unknown Object (File)
Oct 20 2024, 1:17 AM
Unknown Object (File)
Oct 20 2024, 1:17 AM
Unknown Object (File)
Oct 20 2024, 1:17 AM
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 Not Applicable
Unit
Tests Not Applicable

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.