Page MenuHomeFreeBSD

uma: Introduce per-domain reclamation functions
ClosedPublic

Authored by markj on Apr 9 2021, 11:02 PM.
Tags
None
Referenced Files
Unknown Object (File)
Oct 13 2024, 12:47 AM
Unknown Object (File)
Oct 7 2024, 8:38 PM
Unknown Object (File)
Oct 4 2024, 8:26 PM
Unknown Object (File)
Oct 4 2024, 5:57 PM
Unknown Object (File)
Oct 4 2024, 11:27 AM
Unknown Object (File)
Oct 2 2024, 1:16 AM
Unknown Object (File)
Sep 30 2024, 7:41 PM
Unknown Object (File)
Sep 30 2024, 9:48 AM
Subscribers

Details

Summary

Make it possible to reclaim items from a specific NUMA domain.


- Add uma_zone_reclaim_domain() and uma_reclaim_domain().
- Permit parallel reclamations. Use a counter instead of a flag to
synchronize with zone_dtor().
- Use the zone lock to protect cache_shrink() now that parallel reclaims
can happen.
- Add a sysctl that can be used to trigger reclamation from a specific
domain.

There is one issue I am not sure how to resolve. uma_reclaim()
currently tries to put pressure on bucket sizes. If multiple page
daemons start reclaiming their respective UMA caches concurrently, we'd
be putting extra pressure on the bucket size.

Diff Detail

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

Event Timeline

markj requested review of this revision.Apr 9 2021, 11:02 PM

Looks good to me.

We should definitely reconsider whole bucket size pressure mechanism at some point, but I don't think we should worry about extra pressure right now. I suspect we may have insufficient pressure now. And even if we overpressure it, it should quickly compensate back if there is a lock contention. And if there is no lock contention, then shrink was reasonable. I just think we need some mechanism to create small constant pressure in case there is no memory pressure right now, but it may appear later. We should keep the subsystem fit, not overbloated, even if it is not stressed.

This revision is now accepted and ready to land.Apr 10 2021, 5:16 PM