Manuel Bouyer wrote:
On Thu, May 07, 2009 at 01:03:19AM +0200, Jean-Yves Migeon wrote:Alright, then I am adding Manuel to the loop, as I would like to know why removing the APDP would be a problem comparing to temporarily switching pmaps. Is it a performance or a design issue, NetBSD-specific or anything else?on xen/amd64 there is a separate pmap for kernel and user processes; the kernel never runs in the context of a user process pmap (and user process pmaps have no kernel mappings).
So avoiding the use of APDP under Xen/amd64 would need some re-thinking inside pmap (and more work to get it efficient).
[...]The initial goal was to expand my locking to include protection for the pmap_map_ptes/pmap_unmap_ptes calls, so that APDP entries are cleared by pmap_unmap_ptes(). That way, I could avoid the pmap iterations during save, as I could guarantee that they all APDP entries are left unmapped.note that mapping/unmapping APDP on each pmap_map_ptes/pmap_unmap_ptes call is extremely expensive on amd64. We want to avoid it as much as possible (i.e. change APDP only when another pmap needs to be mapped)
Due to the MMU hypercall?If we ever support MP with Xen, modifying mappings found in APDP will require a full TLB flush on all CPUs that could use these mappings, which will also be very expensive.
I can iterate through pmaps and set the APDP entry to 0 if it is not, during suspension. But IMHO, we will have to revisit the APDP part sooner or later.
-- Jean-Yves Migeon jeanyves.migeon%free.fr@localhost