memory allocation issue loading a kernel module
sean at mcneil.com
Tue Nov 25 00:53:47 PST 2003
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
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
Just thinking "out text",
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.
More information about the freebsd-current