And since we'd have things taking off the rightmost and the leftmost,
but nobody wanting the "middle", we will definitely have to deal
with tree imbalance.
> > 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,
> Sound buffers don't get allocated that often that I would
> call it heavy...
No, I mean I did heavy memory consumption (using xv with the visual
schnauzer to browse directories with 500-1000+ images, then fired
up e.g. xanim on an .avi with sound, and the sound driver loaded
and allocated its buffer no problem.
> > 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.
> With Zlatko's patch, there are min_free_pages/2 pages in
> 16k area's, so it's quite likely that there are even more
> in 8k area's. Even when slab management decides to allocate
> a 16k area, there'll always be one available (if there isn't,
> kswapd will be woken up immediately from swap_tick()).
Still, all the 16k free areas in the world don't guarantee the
existance of a 64k free area. With the reverse page table in
place, it will be child's play to create them by blitting (GFP_ATOMIC
low-order allocations) or intelligently chosen swapping (failed
allocations of all sorts). This sort of thing might help with
the sluggish paging I've seen, since swapping will be driven
by demand as well as a general desire to keep a few free pages
around "just in case of the inevitable".
Keith