Date: Tue, 11 Dec 2007 22:36:39 +0100 From: Olivier Houchard <mlfbsd@ci0.org> To: Mark Tinguely <tinguely@casselton.net> Cc: freebsd-arm@freebsd.org Subject: Re: ARM pmap.c redundant vac_me_harder Message-ID: <20071211213639.GA1115@ci0.org> 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
On Tue, Dec 11, 2007 at 02:10:02PM -0600, Mark Tinguely wrote: > > 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. > True, I just removed it. Thanks ! > --- 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. > Hmm your probably right. Honestly I've never bothered optimizing those, because the number of mappings for a page is typically so low it wasn't worth the pain. But patches would be welcome ;) > Okay, I promise to quit digging through the ARM pmap code. Please don't, this is really appreciated :) Regards, Olivier
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071211213639.GA1115>