From owner-freebsd-arm@FreeBSD.ORG Mon Jan 28 00:17:06 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 6665216A419 for ; Mon, 28 Jan 2008 00:17:06 +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 056D013C447 for ; Mon, 28 Jan 2008 00:17:05 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.2/8.14.2) with ESMTP id m0S0H2a4070814; Sun, 27 Jan 2008 18:17:02 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1201479422; bh=CXQFG8TlyD4ROaxUtKbRZb6yFvkhx6R24E+J2c7 tf/Q=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=ZllaaMxB OvGX8xK+KqTjih2bPgyV+7ADFrY3FGj8+eg0T8M3ruoNBhy92hIOPYNkpcVnOtLRk4r jIJ31O6mkVI5vMF01q2WLSSJXYUGoaDkk/FIaVVwH5ZXKXjNOembvLgaFi5b+mcO31/ 5UWjF6937a6cKkzVxHtmYkw9gqstw= Received: (from tinguely@localhost) by casselton.net (8.14.2/8.14.2/Submit) id m0S0H2XG070813; Sun, 27 Jan 2008 18:17:02 -0600 (CST) (envelope-from tinguely) Date: Sun, 27 Jan 2008 18:17:02 -0600 (CST) From: Mark Tinguely Message-Id: <200801280017.m0S0H2XG070813@casselton.net> To: mlfbsd@ci0.org, tinguely@casselton.net In-Reply-To: <20080128003515.GA32514@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: Mon, 28 Jan 2008 00:17:06 -0000 > 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. > > 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. 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. > 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. --Mark Tinguely.