Re: 2.1.76, nfs client, and memory fragmentation

Alan Cox (alan@lxorguk.ukuu.org.uk)
Sun, 28 Dec 1997 23:14:15 +0000 (GMT)


> However, permanently non-freeable blocks should be rare, temporarily locked
> blocks should be uncommon, and relocatable (= swappable) blocks should
> abound. And with a defragmenter available, especially one which can

No - alas not. Also for 32K chunks you only need 1 of the 8 pages to be
touched to be tied down. Marking immovable objects and trying to land them
in the same buddy blocks might help.

The problem with buddy is you have to clean that specific block out. With
first fit you just have to stick together a handy sized block.

> defragment to order (individual order, that is), the long-term kernel
> allocations can be made larger (and correspondingly less frequent),
> thereby minimizing the fragmentation.

A fair number of long time kernel allocations now are SLAB based so the
SLAB allocator is helping a bit here, but not enough.

> Problem is, it *will* catch up one day. I'd just as soon shoot it now,
> so we can make larger allocations, then actually do something to make
> them happen should they block.

It will catch up with us inevitably. With the SGI ports to do the O2
port we will regularly need to grab 64K contiguous memory blocks. For the
Matrox Meteor you can need to pull several hundred K of contiguous ram.

Alan