Date: Tue, 25 Nov 2003 00:53:39 -0800 From: Sean McNeil <sean@mcneil.com> To: Maxime Henrion <mux@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: memory allocation issue loading a kernel module Message-ID: <1069750418.76394.7.camel@blue.mcneil.com> In-Reply-To: <20031125083144.GF8404@elvis.mu.org> References: <1069747092.75674.6.camel@blue.mcneil.com> <20031125081350.GE8404@elvis.mu.org> <1069748403.76000.1.camel@blue.mcneil.com> <20031125083144.GF8404@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Oh, I absolutely agree. I do not want any hacks. I was hoping that there might be an existing mechanism that was in place that would allow for the purging of unused physical pages by resource hogs. I am reminded of an old OS I was fond of: AmigaOS. It had a real nice feature where applications, drivers, etc. would register a "low memory" callback. Whenever the OS reached certain water-marks, these callbacks would get invoked. It was a nice clean way for shared libraries and drivers to cache things in memory, but then throw them away when things got tight. It is not a big deal for me. This is for a customer of mine and they are OK with loading the module early during boot when memory isn't fragmented yet. Just thinking "out text", Sean On Tue, 2003-11-25 at 00:31, Maxime Henrion wrote: > 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?1069750418.76394.7.camel>