Dan Malek <dan at embeddededge.com> wrote: > > On Jul 26, 2004, at 10:27 PM, Linh Dang wrote: > >> What do you mean by the above sentence? > > Exactly what I said. If you are concerned about the difference in > performance between a BAT mapped space and page tables, > there are many other kernel behaviors that are going to cause > trouble for your software. > >> - 200MB would need 51200 ptes. that means doubling the current number >> of ptes on my system. > > Doubling? I don't think so. How did you measure what you are
# cat /proc/ppc_htab PTE Hash Table Information Size : 256Kb Buckets : 4096 Address : c02c0000 Entries : 32768 User ptes : 326 Kernel ptes : 989 Percent full : 4% Reloads : 29288 Preloads : 17175 Searches : 1791 Overflows : 0 Evicts : 0 Non-error misses: 24468 Error misses : 0 That's about 1315 PTEs (before the applications start.) > currently using? The 51200 PTEs really isn't a lot. Mapping huge just 38 times what currently on my system. > linear spaces with PTEs is actually quite efficient. Small VM spaces > with holes are the killer. Do you actually touch every byte within > that 200 MB space? When the system is working full-steam it's pretty close too that. > >> - If using block mapping doesn't help that much then why would X make >> all the effort to grab MTRRs on X86? > > I dunno. I've never done any performance or feature analysis of x86 > page > tables to discuss this. > >> - why would the kernel use BATs to map its memory? > > It's convenient for some areas of memory. Makes it trivial to write > some forms of IO mapping functions. We can set up some early static > memory maps for kernel initialization. Mainly, we don't pollute the > TLBs > during short interrupt or system calls, allowing the user applications > to > run without having to reload the TLB after such events. Even though > the kernel may use BATs, it still maps everything with page tables and > makes extensive use of them for various memory mapping requirements. I though the kernel (2.6) only use pages for vmalloc. -- Linh Dang ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
