Re: filemon
- In reply to: Warner Losh : "Re: filemon"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 31 Jul 2024 08:27:39 UTC
On Tue, Jul 30, 2024 at 10:02:37PM -0600, Warner Losh wrote: > On Tue, Jul 30, 2024, 12:54 PM Dag-Erling Smørgrav <des@freebsd.org> wrote: > > > Miroslav Lachman <000.fbsd@quip.cz> writes: > > > I'm a bit confused. If I understand it right, you say loader.conf > > > causes less memory fragmentation, but DES said "it still increases low > > > memory fragmentation". So what is true? And is this something to watch > > > out for, or is memory fragmentation not such a big deal? > > > > I used the wrong term. The loader loads the kernel and modules into a > > particular region of memory, while modules loaded after boot can go > > anywhere. Furthermore, modules loaded by the loader cannot be unloaded. > > So loading modules pre-boot does not increase fragmentation, but it uses > > up memory from a much more limited pool than loading them later. > > > > Yea. The lower memory addresses used to matter a lot. Now, we don't have > floppies or devices that care <256MB. Some can only do DMA to < 4GB. So > unless you have a huge RAM dusk compiled in, you're not going to > meaningfully depleate the under 4GB. And we don't treat that memory as > special for allocation so the modules loaded after boot could also wind up > there.... > > So it used to matter a lot. Now it's marginally relevant at best. There are still allocations that must happen below 4G. In particular, until we have CPUs that start directly in long mode, the AP startup code and all its data (initial stack, trampoline page tables etc) must happen below 4G. Same for the sleep/wake trampoline. Usually these special allocations are bound in quantity, so if we were lucky to have them succeed at early run time, they are no longer problem. But still it is enough critical allocations that must occur in low memory, where low is below 4G right now.