Re: Graph of the FreeBSD memory fragmentation
- Reply: Ryan Libby : "Re: Graph of the FreeBSD memory fragmentation"
- In reply to: Bojan_Novković : "Re: Graph of the FreeBSD memory fragmentation"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 09 May 2024 09:34:51 UTC
Am 2024-05-08 18:45, schrieb Bojan Novković: > Hi, > > On 5/7/24 14:02, Alexander Leidinger wrote: > >> Hi, >> >> I created some graphs of the memory fragmentation. >> https://www.leidinger.net/blog/2024/05/07/plotting-the-freebsd-memory-fragmentation/ >> >> My goal was not comparing a specific change on a given benchmark, but >> to "have something which visualizes memory fragmentation". As part of >> that, Bojans commit >> https://cgit.freebsd.org/src/commit/?id=7a79d066976149349ecb90240d02eed0c4268737 >> was just in the middle of my data collection. I have the impression >> that it made a positive difference in my non deterministic workload. > Thank you for working on this, the plots look great! > They provide a really clean visual overview of what's happening. > I'm working on another type of memory visualization which might > interest you, I'll share it with you once its done. > One small nit - the fragmentation index does not quantify fragmentation > for UMA buckets, but for page allocator freelists. Do I get it more correctly now: UMA buckets are type/structure specific allocation lists, and the page allocator freelists are size-specific allocation lists (which are used by UMA when no free item is available in a bucket)? >> Is there anything which prevents https://reviews.freebsd.org/D40575 to >> be committed? > D40575 is closely tied to the compaction patch (D40772) which is > currently on hold until another issue is solved (see D45046 and related > revisions for more details). Any idea about https://reviews.freebsd.org/D16620 ? Is D45046 supposed to replace this, or is it about something else? I wanted to try D16620, but it doesn't apply and my naive/mechanical way of applying it panics. > I didn't consider landing D40575 because of that, but I guess it could > be useful on its own. It at least gives a way to quantify with numbers resp. qualitatively visualize. And as such it may help in visualizing differences like with your guard-pages commit. I wonder if the segregation of nofree allocations may result in a similar improvement for long-running systems. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF