Re: memory allocation issue loading a kernel module

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