Date: Tue, 11 Dec 2007 13:33:31 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: tinguely@casselton.net Cc: freebsd-arm@FreeBSD.org Subject: Re: ARM pmap.c redundant vac_me_harder Message-ID: <20071211.133331.31318824.imp@bsdimp.com> In-Reply-To: <200712112010.lBBKA2qJ016942@casselton.net> References: <20071206230417.GA7366@ci0.org> <200712112010.lBBKA2qJ016942@casselton.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200712112010.lBBKA2qJ016942@casselton.net>
Mark Tinguely <tinguely@casselton.net> writes:
:
: 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.
: --- 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.
: Okay, I promise to quit digging through the ARM pmap code.
Please don't :-). We can always use the help there.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071211.133331.31318824.imp>