Re: Please don't beat me up (was Re: Bugs and wishes in memory management area)

David S. Miller (davem@jenolan.rutgers.edu)
Wed, 27 Nov 1996 16:25:34 -0500


From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Wed, 27 Nov 1996 20:27:11 +0000 (GMT)

> with the buddy system, once you are fragmented, you can do nothing about
> it (other than using double indirection pointers [memory handles] which
> basically emulate paging at a cost we probably dont want to pay?).

There is an even worse problem with the buddy system, especially on CPU's
without 4 way caches. All our structures tend to have the used stuff at
the top and data below. Our kmalloc spends all day landing all the
critical structures on the same cache line..

It is my hope that this problem will be alleviated by the work I am
doing to merge Mark Hemment's SLAB allocator into the 2.1.X tree. It
supports full cache coloring for allocations.

> and the memory handle stuff isnt good for interrupt handlers ... neither
> for SMP? TLB invalidates are basically a hardware-implemented
> 'handle-invalidate' feature ... we cannot really implement this in
> software, can we?

Some CPU's the TLB is software. On all CPU's I know an SMP CPU invalidation
needs software and is relatively expensive.

Bzzt, on the sun4d the SuperSparc's only need the local TLB invaildate
to be done. It is broadcast across the entire system by the bus
watchers in the machine. (as a side note, there is a bug in the bus
watchers on certain revs of the XBUS on the sun4d, if you allow more
than 16 tlb invalidations to be outstanding in the system, a 4 bit
counter overflows in the bus watchers and all hell breaks loose
because everyone now thinks no tlb flushes are live in the system)

--------------------------------------------////
Yow! 10.49 MB/s remote host TCP bandwidth ////
over 100Mb/s ethernet. Beat that! ////
-----------------------------------------////__________ o
David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><