ARM pmap.c redundant vac_me_harder
tinguely at casselton.net
Tue Dec 11 13:48:50 PST 2007
> : 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.
More information about the freebsd-arm