Date: Mon, 28 Jan 2008 13:41:45 +0100 From: mlfbsd <mlfbsd@ci0.org> To: Mark Tinguely <tinguely@casselton.net> Cc: freebsd-arm@freebsd.org Subject: Re: ARM pmap cache flushed after PT modification. Message-ID: <20080128124144.GA41252@ci0.org> In-Reply-To: <200801280017.m0S0H2XG070813@casselton.net> References: <20080128003515.GA32514@ci0.org> <200801280017.m0S0H2XG070813@casselton.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080128124144.GA41252>