From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 23:36:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57901E00; Fri, 28 Nov 2014 23:36:41 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3DBA28D; Fri, 28 Nov 2014 23:36:40 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id i13so5143178qae.27 for ; Fri, 28 Nov 2014 15:36:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J/r+TrftsMFs8fMExsmANaTCDdfuf1bWUTBHu5tpyJ4=; b=jm0mmu7ovFgxq3HSe3t76zoBdY9sGHYUEDYd0JF19SKztLZ2lf+ifjHOe3jYJHrA1t 4lPU7Mwrs3YAH68cBVX9M/jJd1msvOAwHsMRYaD7LdXRGYL97teCExiFZ5RZWaxT3paf LeOphXoOEr7kf8IPqaxfA9A5bSabcHJgiAxIzUawThApzQY8+iqHMxvuHwYbhtsPzbOL qlWpUEsZDbNFOE62YXSf6UJXRD1QmRw+qqbuQ6Ayuh3wVjhcMAdkPD6ogLFW9zAGV9AZ HPzylsOEdSFlrilDasSDoRzEE3vcCdMY6VVtpTuCYTlvMbm/coq35YqtTP1sRENd7jvM CgYw== MIME-Version: 1.0 X-Received: by 10.224.129.9 with SMTP id m9mr67104541qas.50.1417217800113; Fri, 28 Nov 2014 15:36:40 -0800 (PST) Received: by 10.140.23.242 with HTTP; Fri, 28 Nov 2014 15:36:40 -0800 (PST) In-Reply-To: References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> <20141126125806.78f2df97328e807d12746ae3@ulrich-grey.de> <519fde5db60e4fc594956a600c6cad4e@e15be-01.zdv.Uni-Mainz.DE> <1417108193.1055.2.camel@revolution.hippie.lan> Date: Sat, 29 Nov 2014 00:36:40 +0100 Message-ID: Subject: Re: Another Test Run with Alternative pmap Implementation From: Svatopluk Kraus To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 23:36:41 -0000 On Fri, Nov 28, 2014 at 11:17 PM, Adrian Chadd wrote: > On 28 November 2014 at 11:49, Svatopluk Kraus wrote: > > 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]. ;) > > As long as nothing else can preempt that thread on that CPU that'll > mess with your PCPU data, everything is fine. > > Doing sched_pin() just prevents your thread from migrating to another > core whilst it's running; it doesn't prevent something else at a > higher priority from preempting you and also trying to get access to > the same PCPU data. > > (I hit this stuff when playing with the flowtable code which makes > heavy use of pcpu data..) > > > -a > > Generally, it's correct. However, I said in this case. And in this case, it's about curpmap. And curpmap is always same from curthread. So only thing which must be ensured is that curpmap is read from correct PCPU. In other words, curthread should not migrate between reading of cpu number and getting curpmap from associated PCPU. Thus wrapping it by sched_pin() and sched_unpin() is enough. Svata > > > > Svata > > > > [1] > > > http://lists.freebsd.org/pipermail/freebsd-current/2013-February/039858.h= tml > > > > > > > > On Fri, Nov 28, 2014 at 6:50 PM, Adrian Chadd > 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 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 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 > >> >> > 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 wou= ld > >> >> recreate the problems that Ulrich is seeing, but buildworld runs fi= ne > >> >> 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@freebsd.org mailing list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.or= g > " > > > > >