From owner-freebsd-arm@FreeBSD.ORG Tue Dec 11 20:36:11 2007 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54D5016A421 for ; Tue, 11 Dec 2007 20:36:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2375D13C474 for ; Tue, 11 Dec 2007 20:36:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBBKWp8G055183; Tue, 11 Dec 2007 13:32:51 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 11 Dec 2007 13:33:31 -0700 (MST) Message-Id: <20071211.133331.31318824.imp@bsdimp.com> To: tinguely@casselton.net From: "M. Warner Losh" In-Reply-To: <200712112010.lBBKA2qJ016942@casselton.net> References: <20071206230417.GA7366@ci0.org> <200712112010.lBBKA2qJ016942@casselton.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org Subject: Re: ARM pmap.c redundant vac_me_harder X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 20:36:11 -0000 In message: <200712112010.lBBKA2qJ016942@casselton.net> Mark Tinguely 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