Date: Tue, 11 Dec 2007 15:48:25 -0600 (CST) From: Mark Tinguely <tinguely@casselton.net> To: imp@bsdimp.com, tinguely@casselton.net Cc: freebsd-arm@FreeBSD.org Subject: Re: ARM pmap.c redundant vac_me_harder Message-ID: <200712112148.lBBLmPsV025126@casselton.net> In-Reply-To: <20071211.133331.31318824.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> : 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200712112148.lBBLmPsV025126>