Date: Fri, 23 Oct 2009 09:48:12 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: Mark Tinguely <tinguely@casselton.net> Cc: freebsd-arm@freebsd.org Subject: Re: [ARM+NFS] panic while copying across NFS Message-ID: <0C359698-59A4-4213-BC22-9F1483611EB5@mac.com> In-Reply-To: <200910231641.n9NGfN1a006721@casselton.net> References: <200910231641.n9NGfN1a006721@casselton.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 23, 2009, at 9:41 AM, Mark Tinguely wrote:
>
>>
>> On Oct 23, 2009, at 8:22 AM, Mark Tinguely wrote:
>>
>>> 3) pmap.c: PVF_REF is used to invalidate cache and flush tlb.
>>> PVF_REF
>>> is set by a trap when the page is really use. kernel pages should
>>> assume it is immediately used.
>>
>> This causes problems for me, so I don't think this is quite right.
>> FYI,
>>
>> --
>> Marcel Moolenaar
>> xcllnt@mac.com
>
> Thank-you for the information. Hmmm, how odd. I will give that some
> thought.
>
> To everyone else, I read my last post and a big sorry for incomplete
> sentences.
> It was just a quick list of things that could be changed to
> streamline the
> machine dependant portion of the code.
Also to everyone:
There's a huge amount of instability in the ARM VM/PMAP code.
Things are slightly better when the L2 cache is configured for
write-through, but there's at least 2 issues left:
1. Clustered I/O causes incoherency and pretty much makes the
box useless when you want to run what you just built.
2. PMAP panics in one or two places, typically after a few
minutes/hours of uptime when doing builds.
With a L2 cache the problems are a bit more severe as it adds
I-cache incoherency to the mix, which even prevents running
init(8).
I think w e need to rethink the PMAP layer, because if we keep
trying to patch it, performance will probably worse from what
it is now. Plus, we'll have to deal with physically indexed and
physically tagged caches ASAP, so better modularization helps.
FYI,
--
Marcel Moolenaar
xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0C359698-59A4-4213-BC22-9F1483611EB5>