ARM pmap.c redundant vac_me_harder

[Mark Tinguely]

>  : IMO, there is a redundant vac_me_harder() call in pmap_protect().
>  : The vac_me_harder() is already performed as the last step in pmap_modify_pv()
>  : when the PVF_WRITE flag is changed.
>
>  It looks to my eye like the vac_me_harder() in pmap_modify_pv only
>  happens when the write flag is changed, while the call in pmap_protect
>  is always called.  I've not looked closely enough to know if this
>  difference matters, but I thought I'd mention it to see if you'd
>  considered it.

vac_me_harder (as prefer to call it "fix_caches") only matters when the
write status changes, which is the time to see if caches should be turned off
or back on.

>  : 			--- on a related topic ---
>  : vac_me_kpmap() can cause (2 * n ^ 2) loops of the pv_list. From my rough
>  : pen and paper logic and even rougher coding, I think the vac_me_XXXX routines
>  : can be combined together and the user scan can be kept at (2 * n) loops
>  : and the kernel cache fixup can be done in (3 * n) loops at the cost of
>  : adding a couple variables to the pmap structure. Since the variables are
>  : in the pmap, only one scan can be done at a time - which would not be a
>  : problem on uniprocessors.
>
>  No, but mutlicore ARM is around the corner, so we don't want to paint
>  ourselves into too much of a corner.

I am exploring the ARM implementation in a hacker/theorist/dreamer mode.

Actually, I had thought of multiple ARM per device such as cellphones,
but I did not know if they were NUMA. Multiple processors are not
that big of a problem, a lock could keep the scan sequential (actually
the vm_page_queue lock should already do that), or this is symmetrical
enough that per cpu variables could be added instead.

IMO, there are some PMAP_LOCKS missing in the vac_me_XXX code; we are clearing
changing pte and pv_flags without locks. It was in the inserting those missing
locks that I started to say "hmmm, would vm_page_queue_mtx prevent the need
to drop the existing lock (for the pmap "pm") if I could not get a pmap lock
for the new pmap entry while traversing the pv_list?". That is why I made a
safer claim of uniprocessor stable.

I respect Olivier's accessment that the pv_lists are shallow enough
for this to not matter - I suppected that this was the case; ARM devices
are not general computing devices.

--Mark Tinguely.