Date: Tue, 23 Mar 2010 07:56:37 -0500 (CDT) From: Mark Tinguely <tinguely@casselton.net> To: gjb@semihalf.com, tinguely@casselton.net Cc: freebsd-arm@freebsd.org, cognet@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable Message-ID: <201003231256.o2NCubIw018755@casselton.net> In-Reply-To: <4BA8A284.1060508@semihalf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> From gjb@semihalf.com Tue Mar 23 06:14:23 2010 > X-Virus-Scanned: by amavisd-new at semihalf.com > Date: Tue, 23 Mar 2010 12:14:12 +0100 > From: Grzegorz Bernacki <gjb@semihalf.com> On Tue, 23 Mar 2010 12:14:1, Grzegorz Bernacki wrote: > Patch I've send is not a solution for this problem. I just send it to show > that excluding executable pages from fix_cache mechanism fixes the problem > and as I wrote in this mail, we need to handle executable pages with writable > kernel mapping differently. > I think that Mark is right. Kernel mapping should be already flushed out (we > can just do it again to make sure). I am not sure it there is any chance that > user mapping can have some cached data. > > grzesiek This pmap_fix_cache happens at (un)mapping time, if we had to, we could modify the DMA sync code too. I am thinking on the PVF_EXEC POST_READ sync to invalidate both the kernel and user cache. For example, my experimental busdma_machdep.c could keep vm_page entries for the non-bounced cache; it also could be computed with a pmap_extract. The bounce list could add the vm_page entry or compute it simply from the PA. --Mark.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201003231256.o2NCubIw018755>