Hi, I'm tuning pmap code for arm11 mpcore port, which is inspired by i386 one. My question is about superpage promotions on kernel addresses in i386 pmap code. pmap_promote_pde() is called from pmap_enter() only and if following conditions are fulfilled:
1. promotions are enabled, 2. all pages in a superpage are allocated (physical space condition), and for user addresses, 3. all pages in a superpage are mapped (virtual space condition). For kernel addresses, the third condition is not checked. I understand that it is not easy to evaluate the third condition for kernel addresses. However, pmap_promote_pde() often can be called unnecessarily now and it's rather expensive call. Or is there any other reason for that? Moreover, there are many temporary mappings (pmap_qenter(),...) in kernel and if pmap_promote_pde() is called without 3th condition, the promotion can be successfull. As temporary mappings do nothing with promotions and demotions, it is a fault. Or a superpage with temporary kernel mapping never can be promoted because of locking or something else? The third condition is evaluated on page table bases (wire_count is used) for user addresses. Page tables for kernel addresses have wire count set to 0 or 1. Page tables preallocated during boot are post-initialized in pmap_init() but wire_count is left untouched (wire_count is 0). Page tables allocated in pmap_growkernel() are allocated wired (wire_count is 1). [branch] If a kernel superpage is demoted in pmap_demote_pde() and corresponding page table wire_count is 1, the page table is re-initialized uselessly as a newly allocated one. My idea is that kernel address mappings made in pmap_enter() can be marked 'stable' (as opposite to 'temporary') and counted by wire_count in same way as for user addresses and then third condition could be applied and will be fulfilled only for this 'stable' mappings (which know about promotions and demotions). Is anything wrong with this idea? Svata _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"