Messages in this thread |  | | Date | Wed, 27 Nov 1996 16:25:34 -0500 | From | "David S. Miller" <> | Subject | Re: Please don't beat me up (was Re: Bugs and wishes in memory management area) |
| |
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 /_____________/ / // /_/ ><
|  |