On Mon, Mar 18, 2002 at 02:12:48PM +0000, Brian J. Beesley wrote: > On Monday 18 March 2002 10:21, Nick Craig-Wood wrote: > > There has been some discussion on the linux kernel mailing list about > > providing 2 MB pages (instead of 4kB ones) to user space for the use > > of database or scientific calculations. > > > > It seems to me that prime95/mprime would benefit from this enormously > > - it should reduce the TLB thrashing to practically zero and hence > > speed up mprime by some unknown amount. > > > > Is this true? Should we put in our plea to the developers? > > Other people may and probably will disagree, but I think it will make very > little if any difference for most applications.
For most applications yes - however it would be configurable in a per-process manner. Possibly each process might have to take special action to get 2 MB pages - say a new flag to memmap(). > The point is that mprime should normally be running on a system in a way > which means that all its active data pages are in memory. Having active data > paged out will cause a hideous performance hit. > > If the active data is already memory resident, TLB thrashing is not going to > be an issue. The TLB (translation lookaside buffer) has very little to do with the Virtual Memory system. The TLB is used by the processor to cache the address translations from logical memory to physical memory. These have to be read from the page table RAM which is expensive - hence the cache. When I was working on a DWT implementation for StrongARM I found that thrashing the TLB caused a factor of two slow down. The StrongARM system I was using had no virtual memory. If mprime is using 10 MB of memory say, then each page needs 1 TLB entry to be used at all by the processor - ie 2560 TLB entries which is way bigger than the size of the TLB in the processor (I don't remember what it is in x86 but on StrongARM it has 32 entries). To access each physical page the TLB has to be reloaded from the page tables which is an extra memory access or two. If you use 2 MB pages then there are only 5 pages needed and hence the TLB will never need to be refilled and hence some speed gain. > If the page size is going to be changed at all, there is a lot to be > said for using the same size pages as AGP hardware - 4MB I think - > there have already been some issues on some Athlon (K7) architecture > linux systems caused by incorrect mapping between linux virtual > pages and AGP address space; obviously using the same page size > removes this source of confusion. The choice of page size is constrained by the memory management hardware. I think 4k and 2 MB are the only sensible choices but I may be wrong. > One factor with shifting to a much larger page size is a > corresponding decrease in the number of pages available to the > system - a 32 MByte system will have only 8 4MB pages resident in > real memory at any one time. Since page access rules are often used > to protect data from accidental modification by rogue pointers etc., > a big reduction in system physical page count is a distinctly mixed > blessing. The proposal was that you would be able to turn on 2 MB pages for a given process - obviously you wouldn't want 2 MB pages for every process unless you had > 100 GB of RAM. I think this would make a real difference to mprime - what percentage I don't know - at the cost of on average 1 MB of RAM extra. -- Nick Craig-Wood [EMAIL PROTECTED] _________________________________________________________________________ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
