From owner-freebsd-arm@FreeBSD.ORG Thu Jan 17 15:49:01 2008 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 0936116A41B for ; Thu, 17 Jan 2008 15:49:01 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id B4D6C13C47E for ; Thu, 17 Jan 2008 15:49:00 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.13.8/8.13.8) with ESMTP id m0HFmskW003606; Thu, 17 Jan 2008 09:48:54 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1200584934; bh=uwNJciW4D8ebKInOhT5FpMmS0aecbhiNcjuR5Lm CgOs=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=jm3HLo7m YZTjwEhk/26YhD9qcSwco8TRnJA/8Lza2WgI8nhnHLqNvZ0sZYk3yJ/eSXhZknbz+l7 hLyZjhSnHHJFXDfeCaV12JD5+lhhj68sxsQipk9Bl8V1vSBBFbSPxIfozt4hplrC9cJ bH1p1SI8Owzzn8w6iybJFK5b5TNA0= Received: (from tinguely@localhost) by casselton.net (8.13.8/8.13.8/Submit) id m0HFmsFH003605; Thu, 17 Jan 2008 09:48:54 -0600 (CST) (envelope-from tinguely) Date: Thu, 17 Jan 2008 09:48:54 -0600 (CST) From: Mark Tinguely Message-Id: <200801171548.m0HFmsFH003605@casselton.net> To: mlfbsd@ci0.org, tinguely@casselton.net In-Reply-To: <20080117001757.GA63358@ci0.org> Cc: freebsd-arm@freebsd.org Subject: Re: ARM pmap cache flushed after PT modification. 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: Thu, 17 Jan 2008 15:49:01 -0000 At http://www.casselton.net/~tinguely/armpmap_fixcache.c is the recent file that holds my idea/suggestions. Below is is a brief explaination of all the changes: pmap_get_vac_flags(), pmap_vac_me_harder(), pmap_vac_me_kpmap(), and pmap_vac_me_user() has been rewritten as pmap_fix_cache() to be more efficient in the kernel map case. I also removed the reference to the md.kro_mappings, md.krw_mappings, md.uro_mappings, and md.urw_mappings counts. There is bug in pmap_vac_me_kpmap() in the case where a writable kernel mapping is added to a page that already mapped to a user map, the kernel mapping is left as cachable. IMO, this is not the normal way that pages are added. The error is in the line 1416: pmap_vac_me_user(pg, pm, va); which undoes the previously set no-caching. I can give the shell of the testing program for the pmap_vac_me_XXX() and the new pmap_fix_cache() if you wish to see it. There are tons of test cases that need to be run, I don't have all them anymore. ----- In pmap_clearbit(), we can also skip over tests and writeback/invalidations in the PVF_MOD and PVF_REF cases if those bits are not set in the pv_flag. PVF_WRITE will turn caching back on and remove the PV_MOD bit. ----- In pmap_nuke_pv(), the vm_page_flag_clear(pg, PG_WRITEABLE) has been moved to the pmap_fix_cache(). We can be more agressive in attempting to turn caching back on by calling pmap_fix_cache() at times that may be appropriate to turn cache on (a kernel mapping has been removed, a write has been removed or a read has been removed and we know the mapping does not have multiple write mappings to a page). ----- In pmap_modify_pv() is just a conversion from pmap_vac_me_harder() to pmap_fix_cache(). ----- In pmap_remove_pages() the cpu_idcache_wbinv_all() is moved to happen before the page tables are NULLed because the caches are virtually indexed and virtually tagged. ----- In pmap_remove_all(), the pmap_remove_write(m) is added before the page tables are NULLed because the caches are virtually indexed and virtually tagged. This also removes the need for the caches fixing routine (whichever is being used pmap_vac_me_harder() or pmap_fix_cache()) to be called on any of these mappings. ----- In pmap_remove(), I simplified the cache cleaning process and removed extra TLB removals. Basically if more than PMAP_REMOVE_CLEAN_LIST_SIZE are removed, then just flush the entire cache. --Mark.