I prefer such silly softwares to make problems to users, in order they
will be fixed more quickly.
On the other hand, try_to_free_pages() and friends do not care
too much with needs of contiguous physical memory larger than 1 PAGE.
So, in my opinion, your patch is a bomb and I would prefer it to be
disgarded, at least for the moment.
It is always possible to use physical memory area not larger than 1 PAGE,
on a running system for the following reasons:
- If such memory is to be used for DMA, it is possible to use
scatter/gather technics, or to fall to multiple IOs with device
drivers that do not support scatter/gather.
- If such memory is only accessed by the CPU, it is possible to virtually
remap severall PAGES in a way they can be addressed contiguously.
- For very rare situations in which large physically contiguous memory
chunks are needed or wished, it is possible to allocate them at boot up or
very early after the system has been booted up.
Gerard.
On Sat, 29 Mar 1997, Marek Michalkiewicz wrote:
> Hi,
>
> some time ago I wrote a small kernel patch to fix a bug with kmalloc()
> failing to allocate large memory blocks (>1 page). I sent this patch
> to the linux-kernel list, and it's on the "unofficial Linux 2.0 patches"
> web page (http://www.ecsnet.com/html/linux_upatch.html), but I haven't
> received any feedback on it so far.
>
> The patch is very small so I'm including it here. Please try it
> and tell me if you see any problems with it. If there are none,
> would it be possible to include it in 2.0.30?
>
> The problem the patch is trying to address is that we don't try
> hard enough to free some pages - if (nr_free_pages > reserved_pages),
> GFP_KERNEL is effectively the same as GFP_ATOMIC. But we may have
> enough free pages, just not in a single contiguous physical memory
> block. So, we should try to free more pages until we either succeed
> (allocate the block) or can't free any more pages.
>
> There are certainly better ways to do it (currently it just tries
> to free random pages until it succeeds) but still I think it is
> better than nothing. ftape DMA buffers, resizing to large screens
> in SVGATextMode, etc. should benefit from it. While there may be
> a better fix in 2.1.x, this one should be good enough for 2.0.x.
[ patch removed ]