Another Test Run with Alternative pmap Implementation

[Adrian Chadd]

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 at 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 at freebsd.org> wrote:
>
>> On Wed, 2014-11-26 at 22:18 +0000, Weiß, Dr. Jürgen 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 sanity
>> 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 warning
>> 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 arm
>> system without adding a lot of value.  I usually leave it off, sometimes
>> turn it on when I encounter a problem to see if it generates more info
>> (usually it doesn't).
>>
>> -- Ian
>>
>>
>>
>
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"