From owner-freebsd-arm@FreeBSD.ORG Tue Dec 11 20:38:33 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 5749716A417 for ; Tue, 11 Dec 2007 20:38:33 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (dong.ci0.org [IPv6:2001:7a8:2066:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id A5DF413C448 for ; Tue, 11 Dec 2007 20:38:32 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.14.1/8.13.8) with ESMTP id lBBLaeCT001181; Tue, 11 Dec 2007 22:36:40 +0100 (CET) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.14.1/8.13.8/Submit) id lBBLaehK001180; Tue, 11 Dec 2007 22:36:40 +0100 (CET) (envelope-from mlfbsd) Date: Tue, 11 Dec 2007 22:36:39 +0100 From: Olivier Houchard To: Mark Tinguely Message-ID: <20071211213639.GA1115@ci0.org> References: <20071206230417.GA7366@ci0.org> <200712112010.lBBKA2qJ016942@casselton.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200712112010.lBBKA2qJ016942@casselton.net> User-Agent: Mutt/1.4.1i 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:38:33 -0000 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