Date: Thu, 20 Mar 2014 08:42:27 +0100 From: Wojciech Macek <wma@semihalf.com> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: arm SMP on Cortex-A15 Message-ID: <CANsEV8c047SNF61EgP6AiMR2oY=ofcMuTWYZnd60bRmp2Sk9HA@mail.gmail.com> In-Reply-To: <1395254911.80941.9.camel@revolution.hippie.lan> References: <CANsEV8euHTsfviiCMP_aet3qYiK2T-oK%2B-37eay7zAPH2S2vaA@mail.gmail.com> <20131220125638.GA5132@mail.bsdpad.com> <20131222092913.GA89153@mail.bsdpad.com> <CANsEV8fSoygoSUyQqKoEQ7tRxjqDOwrPD8dU7O2V2PXRj35j4A@mail.gmail.com> <20131222123636.GA61193@ci0.org> <CANsEV8fWvUkFHi8DP6Nr807RwPDB1iZrO39fpfa44qOkJPidZA@mail.gmail.com> <1395149146.1149.586.camel@revolution.hippie.lan> <1395254911.80941.9.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Ian, Thanks, I looked at your patch and tried to run it. Unfortunatelly, it is still something wrong on A15 core. Your changes in pmap_kenter_internal do cause panics during startup. Apparently we still need to do cpu_tlb_flushID_SE(va) at the end of that function... but that is weird. I made this small "fix" and I'm able to boot the system. I'm going to run stress tests now to see if it is stable. Regarding DEBUG, that is really interesting. It you see that on A9 that seems to be even worse, because suggests a flaw in pmap logic... Wojtek 2014-03-19 19:48 GMT+01:00 Ian Lepore <ian@freebsd.org>: > On Tue, 2014-03-18 at 07:25 -0600, Ian Lepore wrote: > > On Mon, 2014-03-17 at 09:29 +0100, Wojciech Macek wrote: > > > Hi, > > > > > > Finally I've found some time to continue SMP hacking. It seems that I > > > isolated the tlb/pmam failures and developed two simple patches that > help. > > > There are still some pmap changes and TEX remap left, but I don't want > to > > > use them now. > > > > https://drive.google.com/folderview?id=0B-7yTLrPxaWtSzZPUGgtM3pnUjg&usp=sharing > > > * 01 - ensure that TTB is set before TLB invalidation and flush BTB to > > > comply the specs > > > * 02 - add missing TLB invalidations to pmap and fix invalidation order > > > > > > I chose buildworld -j4 as a stresstest, and run it on Arndale (USB > rootfs) > > > and a different 4-core a15 chip (SATA rootfs). On both setups test > passed > > > and was significantly faster than the one with previous patchset. > > > > > > I'd like to submit these changes to FreeBSD tree (with some help from > our > > > local committers), so any comments and testing are really appreciated. > > > > > > Best regards, > > > Wojtek > > > > The first patch looks fine and is working without any problems for me. > > > > For the second patch, I propose the attached similar patch which > > combines your changes with some I got from Olivier. The main > > differences are moving the tlb flush outside the loop when propagating a > > change to all L1s, and moving the tlb flush (rather than adding another) > > in pmap_kenter_internal(). > > > > I believe even with the second patch there may still be some missing tlb > > flushes. > > > > -- Ian > > Following up with a third version of the pmap-v6.c patch. On top of the > previous versions, this: > > * ensures that cpu_cpwait() is consistantly used after every tlb > flush (sometimes it's a single wait after flushes that happen in > a loop). > * adds a tlb flush to pmap_free_l2_bucket() > * adds a tlb flush to pmap_bootstrap() > * adds a tlb flush to pmap_grow_map() > * adds a tlb flush to pmap_grow_l2_bucket() > * adds a tlb flush to pmap_kenter_section() > > I'm not sure there's any armv6/7 platform that needs the cpu_cpwait(), > but if it's going to appear in the code at all, it should at least be > consisant. :) > > -- Ian > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANsEV8c047SNF61EgP6AiMR2oY=ofcMuTWYZnd60bRmp2Sk9HA>