> I think his patch is worth a try. It might be a bit late
> for 2.2, but it should definately go into 2.3.
> For 2.2 we'll have to go with the tried and tested stuff
> such as:
> - Zlatko's defragmentation patch
This is the patch which blindly swaps out more stuff until you happen
to get half the minimum freepages in order-2 free areas? This seemed
to hurt performance on my 32M machine at the time; others' mileage may
vary. That said, is effective in the case of the 16k and smaller free
areas being needed... It does also use a very different interpretation
of the minimum free pages value, which I object to simply because we
should all be using one meaning for it, not because I like his meaning
less than the unpatched kernel's meaning.
> - Linus' old allocation algoritm
Linus's new algorithm seems stable, it's just that performance
benefits are unknown. Minimum free pages goals aren't touched, just
minimum low-priority-allocatable pages...
> - the 'two-way' allocation, letting the user pages alloc
> from the top of memory, so the free areas gravitate to
> the lower end of memory
What two-way allocation? My patch, which doesn't do anything useful
if about half your memory is/isn't DMA-capable? Otherwise you're
saying we can't include new stuff but we should include stuff we
haven't even written yet... Modifying my (stable) patch to
discriminate on an address halfway through physical memory would
help; otherwise you'd have to cope with multiple free lists for
each order, or you'd need to pull in some stock, well-tested,
lean balanced (red-black or avl) binary tree code.
> The 'two-way' allocation should be easy to add, I'll do
> that too, if I've got some time left in the morning :-)
*ahem*. If you want to argue for stable code, argue for stable
code that's already been written. :-)
> Oh, with Zlatko's code I've hardly had any trouble with
> memory fragmentation... It's tried and tested for over
> 3 months on a lot of people's systems so it's ready for
> the kernel, IMO.
Hmm. FWIW, without Zlatko's code but with Linus's and my fragment
reservation/fragment discrimination patches I've had no problems
with allocating, e.g. sound buffers after heavy memory consumption,
but the same is very much not true of 8k NFS packets (especially
now that I upgraded to fast ethernet :-(). I'd guess that if
Zlatko's patch frees enough 16k areas, it's probably freeing
enough 64k areas that we don't have to worry too much.
Keith