i386 - pmap_enter() & superpage promotion on kernel addresses

[Svatopluk Kraus]

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