Date: Sun, 27 Jan 2008 18:17:02 -0600 (CST) From: Mark Tinguely <tinguely@casselton.net> To: mlfbsd@ci0.org, tinguely@casselton.net Cc: freebsd-arm@freebsd.org Subject: Re: ARM pmap cache flushed after PT modification. Message-ID: <200801280017.m0S0H2XG070813@casselton.net> In-Reply-To: <20080128003515.GA32514@ci0.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801280017.m0S0H2XG070813>