Date: Tue, 25 Nov 2003 09:31:44 +0100 From: Maxime Henrion <mux@freebsd.org> To: Sean McNeil <sean@mcneil.com> Cc: freebsd-current@freebsd.org Subject: Re: memory allocation issue loading a kernel module Message-ID: <20031125083144.GF8404@elvis.mu.org> In-Reply-To: <1069748403.76000.1.camel@blue.mcneil.com> References: <1069747092.75674.6.camel@blue.mcneil.com> <20031125081350.GE8404@elvis.mu.org> <1069748403.76000.1.camel@blue.mcneil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sean McNeil wrote: > Yes, thanks for the clarification. I still am inclined to believe, > though, that the disk driver is what is fragmenting the physical memory > with disk cacheing. It is only a theory, but it sounded plausible. Maybe, but the root cause is not the disk caching. It may be that this subsystem is doing a lot of allocations/deallocations and thus leads to physical address space fragmentation, but the root cause is how we deal with physical address space, and the correct fix is not to add hacks into the disk caching code. I'm insisting on this because I don't want to see people adding hacks here and there to workaround the problem. Even if you get the disk caching code to cause less fragmentation, fragmentation _will_ happen. At best it'll take a bit longer. Cheers, Maxime
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031125083144.GF8404>