Page MenuHomeFreeBSD

uma: allow uma_zfree_pcu(..., NULL)
ClosedPublic

Authored by kp on Mar 10 2021, 3:40 PM.
Tags
None
Referenced Files
F115281053: D29189.id.diff
Tue, Apr 22, 4:58 AM
Unknown Object (File)
Sun, Apr 20, 6:57 PM
Unknown Object (File)
Sun, Apr 20, 5:08 PM
Unknown Object (File)
Sun, Apr 20, 3:19 PM
Unknown Object (File)
Sun, Apr 20, 12:44 AM
Unknown Object (File)
Sat, Apr 19, 10:54 AM
Unknown Object (File)
Thu, Apr 17, 10:29 AM
Unknown Object (File)
Thu, Apr 17, 6:41 AM
Subscribers

Details

Summary

We already allow free(NULL) and uma_zfree(..., NULL). Make
uma_zfree_pcpu(..., NULL) work as well.
This also means that counter_u64_free(NULL) will work.

These make cleanup code simpler.

MFC after: 1 week
Sponsored-by: Rubicon Communications, LLC ("Netgate")

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kp requested review of this revision.Mar 10 2021, 3:40 PM

So the weird thing about pcpu pointers is that they're not pointers in the usual sense. We add some per-CPU offset to the value to get a real pointer. In fact, on amd64, zpcpu_get(NULL) will give a pointer with value &curthread. OTOH, uma_zalloc_pcpu() returns NULL to indicate failure, so I guess it should be ok to treat that value specially here too.

This revision is now accepted and ready to land.Mar 10 2021, 3:57 PM
This revision was automatically updated to reflect the committed changes.

They originally were pointers and counter_u64_free(NULL) worked. That was regressed with fb886947d97375ea9906fa1396f83573b6d0674b I think

They originally were pointers and counter_u64_free(NULL) worked. That was regressed with fb886947d97375ea9906fa1396f83573b6d0674b I think

We used to use plain uma_zalloc()/_zfree() with PCPU zones, so counter_u64_free(NULL) worked. There was a change to add dedicated KPIs for PCPU zones to reduce branching in the fast path, I believe this is where the behaviour changed. 4e180881ae4a325cfaeef336aa1a16b0d5bbae67