Date: Fri, 28 Nov 2014 20:49:16 +0100 From: Svatopluk Kraus <onwahe@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Ian Lepore <ian@freebsd.org> Subject: Re: Another Test Run with Alternative pmap Implementation Message-ID: <CAFHCsPWg=A-DvCqm0if13z=GM3EK5gbgC1Dww_90hQBFbixW9w@mail.gmail.com> In-Reply-To: <CAJ-Vmok=yN4EqMucLCz=ZkoUv8pGnp8FHTzLo%2BTuXFE2_K1CMg@mail.gmail.com> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <C6FED1A5-490C-47BE-B071-484271ED370E@me.com> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <CAFHCsPUJ1HhLqAjitPg6mPzhMYSui64Xmu4omO7Pkp%2B0kPZnAA@mail.gmail.com> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <CAFHCsPXnSFY_X-O73M%2Bh0xO_XJ0cTmkRwtu-o4omPndnfbEhmg@mail.gmail.com> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <CAFHCsPWTnU7j0MC7YSHFFDE97%2B%2BBrnkJKGnK9zkxVGemaa6nAw@mail.gmail.com> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> <CAFHCsPXPEN3U%2B0=AtAJ4dL5g7jGuyW6=u%2B-tbHf3xH1QdJYyhQ@mail.gmail.com> <20141126125806.78f2df97328e807d12746ae3@ulrich-grey.de> <519fde5db60e4fc594956a600c6cad4e@e15be-01.zdv.Uni-Mainz.DE> <1417108193.1055.2.camel@revolution.hippie.lan> <CAFHCsPWL94b5JFL87__MxGfGFrA4q0c3QgPwZf7MGzJ9i6hsaQ@mail.gmail.com> <CAJ-Vmok=yN4EqMucLCz=ZkoUv8pGnp8FHTzLo%2BTuXFE2_K1CMg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for explanation. In this case, however, wrapping by sched_pin() and sched_unpin() calls would be enough. Nevertheless, as our pmap is based on i386 one, I asked Alan Cox for the meaning of this warning and created patch according to his answer. More about PCPU stuff could be found in [1]. ;) Svata [1] http://lists.freebsd.org/pipermail/freebsd-current/2013-February/039858.htm= l On Fri, Nov 28, 2014 at 6:50 PM, Adrian Chadd <adrian@freebsd.org> wrote: > Hi, > > PCPU_GET()ed things aren't atomic. Unless you're in a critical > section, you can be pre-empted at any time and migrated to another > CPU. There aren't explicit "migration points" that kernel code can be > migrated - it can be pre-empted and migrated to other CPUs whenever > something else at a higher priority comes along. > > So if you're not wrapping your PCPU_GET() and subsequent work inside a > critical section - if you're using the PCPU_GET()'ed data outside of > the critical section, then you're in for a world of trouble. > > > > -adrian > > > On 28 November 2014 at 01:31, Svatopluk Kraus <onwahe@gmail.com> wrote: > > I think that the pmap_remove_page warning is very likely due to not > atomic > > PCPU_GET(). Can you please try attached patch. > > > > Svata > > > > > > > > On Thu, Nov 27, 2014 at 6:09 PM, Ian Lepore <ian@freebsd.org> wrote: > > > >> On Wed, 2014-11-26 at 22:18 +0000, Wei=C3=9F, Dr. J=C3=BCrgen wrote: > >> > I made a testrun with the updated source tree and the patches for > >> > the jetson tk1 platform. With > >> > > >> > options ARM_NEW_PMAP > >> > options DEBUG > >> > options DIAGNOSTIC > >> > options INVARIANTS # Enable calls of extra sani= ty > >> checking > >> > options INVARIANT_SUPPORT # Extra sanity checks of > >> internal structures, required by INVARIAN > >> > > >> > and no special sysctl settings. > >> > > >> > A make -j6 buildworld finishes successfully after 2h15m. There is > >> > one kernel message > >> > kernel: warning: pmap_remove_pages called with non-current pmap > >> > > >> > /usr/src and /usr/obj over nfs, /tmp on tmpfs > >> > > >> > Regards > >> > >> That's similar to my results. I changed to -j20 to see if that would > >> recreate the problems that Ulrich is seeing, but buildworld runs fine > >> for me, in about 2 hours. I've never seen the non-current pmap warnin= g > >> on the system that uses a usb ssd drive as root, but I've seen it with > >> nfs root. > >> > >> BTW, the DIAGNOSTIC option adds a LOT of performance overhead to an ar= m > >> system without adding a lot of value. I usually leave it off, sometim= es > >> turn it on when I encounter a problem to see if it generates more info > >> (usually it doesn't). > >> > >> -- Ian > >> > >> > >> > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPWg=A-DvCqm0if13z=GM3EK5gbgC1Dww_90hQBFbixW9w>