From owner-freebsd-arm@FreeBSD.ORG Mon Jan 28 11:31: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 CDEBB16A417 for ; Mon, 28 Jan 2008 11:31:01 +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 C4E1213C467 for ; Mon, 28 Jan 2008 11:31:00 +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 m0SCfkJ2041484; Mon, 28 Jan 2008 13:41:46 +0100 (CET) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.14.1/8.13.8/Submit) id m0SCfjlK041483; Mon, 28 Jan 2008 13:41:45 +0100 (CET) (envelope-from mlfbsd) Date: Mon, 28 Jan 2008 13:41:45 +0100 From: mlfbsd To: Mark Tinguely Message-ID: <20080128124144.GA41252@ci0.org> References: <20080128003515.GA32514@ci0.org> <200801280017.m0S0H2XG070813@casselton.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200801280017.m0S0H2XG070813@casselton.net> User-Agent: Mutt/1.4.1i 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: Mon, 28 Jan 2008 11:31:01 -0000 On Sun, Jan 27, 2008 at 06:17:02PM -0600, Mark Tinguely wrote: > > > I'm just nitpicking here, but maybe, if the page is cacheable, it would be > > cheapier to just parse the mapping list once, instead of calling pmap_fix_cache > > Something like this : > > if ((pve->pv_flags & PVF_NC) && ((pm == pmap_kernel()) || > > (pve->pv_flags & PVF_WRITE) || !(pve->pv_flags & PVF_MWC))) > > pmap_fix_cache(pg, pm, 0); > > else { > > TAILQ_FOREACH(pve, &pg->md.pv_list, pv_list) > > if (pve->pv_flags & PVF_WRITE) > > break; > > if (!pve) { > > pg->md.pvh_attrs &= ~PVF_MOD; > > vm_page_flag_clear(pg, PG_WRITEABLE); > > } > > } > > It works for me. > Ok, I'll commit something similar then. > > > > Yeah I'd love to work with armv6, but haven't been able to get my hand on > > hardware yet. > > I haven't read the doc yet, but I thought armv6 had a physically tagged cache. > > So why would we need to flush it on context switch at all ? > > You would not have to, but in the single core case, they still virtually > index the cache - if the cache is greater than 16KB, then the cache > set width is wider than 4KB, so a page can be listed (aliased) in the > cache in more than one place - that is why page coloring is needed. > ARMv5 would need page coloring, but they made the cache set width 1KB, > so small pages would not be aliased in the wrong place. > Ok got it, I thought even UP had a physically indexed cache. > The multicore uses a physical indexed cache, so duplicates (alias) in the > cache is not possible. > > I like the ARMv6 ASID feature too - so 256 different maps can be active at > once, the MMU will keep those VA seperate. For example all the kernel > programs (swapper, interrupt, etc) can be one space and 255 other > processes can be active - should be enough for a embedded computer. > Yes I read about this, I like it too, would make CS so much faster. > > I know NetBSD is starting to implement armv6 support (what they had before > > for arm11 was just mimicking armv5). It would be interessant to watch their > > approach. > > Make sense. I am still toying with recursive page tales ideas. > Olivier