From owner-freebsd-ppc@freebsd.org Wed May 13 15:56:37 2020 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E48032F9A18; Wed, 13 May 2020 15:56:37 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49MfRm6J8hz4Cjp; Wed, 13 May 2020 15:56:36 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-qk1-x741.google.com with SMTP id y22so5219351qki.3; Wed, 13 May 2020 08:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=AorPKGANpreDu+Uw1/aaP88YkeF7NB6uV/b4eKDQVhM=; b=k/Jk0ssqncUGxCMPu4IbpADHW9LkIeL34iOrXY+5Biyx5dpZcFFQQkDlVmdZuQMiwK gm2hU67eOn95FWgA4URmJNUVXu2wtwxVKtn7NqBnRCUilvHTScxG+02l7bYRY0L3iXC0 Ndsl+We+OBBmD9hxfKVys770l/BPGIO5hctvOtgealtnLeAx6j2TQ+DHYw9mLSTR9lRV 2lHaGpvNpCtirWL+3/ksD8C4ZaPhGJUUmEAlUM56sASYB0x/0dQNJnd/9KXaATB4Na74 q3rAxUB9AsevB+DoWb2pVV/ceJg18ha99k+l+XmtjNAJUBP7U0IskDMbNteNFb1LeQkR XzSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=AorPKGANpreDu+Uw1/aaP88YkeF7NB6uV/b4eKDQVhM=; b=gY2LTAaP49eLwPgVK7iDhYp4M2ijXpY2lg5L3pQkIRtdybExHSLGl3GuyCUEDucUhv gS1vzJdntkFHIpcdn5DzF9wV3umCshMoCzp+y9Bss4bawwLOs30ud0SwDVH0Xy5WuWT0 3ZpmjpbFfiOouzFFtC6BGh2ybrMNCVE/a9aB2AMmfpU/7p8Vooxev+jIRjoK92xh3hp9 IGSYFUrY8iXpHRbaqN8kUfHZq/f9hurJ+vA2gO37piNMW1SML07AJwuOKjstAlf3ZC4w NgMY9GMOg9Ght7mD98aJbr9Ls4GD8gVlBaSmJ0r0qZGopzkG4RHFe7XLAlaZIyLf6f+C F1WA== X-Gm-Message-State: AOAM531fgmCnqeK/NQYPeWTHoglY8cKGB3SjPucJgndPq6KdzcPQKgsm 09hSGpocpwl3D2MJncxrl5I= X-Google-Smtp-Source: ABdhPJy32QdNkjYh2lRrNzio3NWbm85r3Q1aP+/yT6mGNVhkcHOzzmYpla1TZNMld0yrVLw0/eRKNA== X-Received: by 2002:a37:a687:: with SMTP id p129mr343629qke.45.1589385395999; Wed, 13 May 2020 08:56:35 -0700 (PDT) Received: from titan.knownspace (173-19-125-130.client.mchsi.com. [173.19.125.130]) by smtp.gmail.com with ESMTPSA id v78sm133399qkb.62.2020.05.13.08.56.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2020 08:56:35 -0700 (PDT) Date: Wed, 13 May 2020 10:56:32 -0500 From: Justin Hibbits To: Mark Millard Cc: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML , Brandon Bergren Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 Message-ID: <20200513105632.06db9e21@titan.knownspace> In-Reply-To: <359C9C7D-4106-42B5-AAB5-08EF995B8100@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> <9562EEE4-62EF-4164-91C0-948CC0432984@yahoo.com> <9B68839B-AEC8-43EE-B3B6-B696A4A57DAE@yahoo.com> <359C9C7D-4106-42B5-AAB5-08EF995B8100@yahoo.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; powerpc64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49MfRm6J8hz4Cjp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=k/Jk0ssq; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of chmeeedalf@gmail.com designates 2607:f8b0:4864:20::741 as permitted sender) smtp.mailfrom=chmeeedalf@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCPT_COUNT_SEVEN(0.00)[7]; FREEMAIL_TO(0.00)[yahoo.com]; RECEIVED_SPAMHAUS_PBL(0.00)[130.125.19.173.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; IP_SCORE(0.00)[ip: (0.01), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.42), country: US(-0.05)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[1.4.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 15:56:38 -0000 Hi Mark, On Wed, 13 May 2020 01:43:23 -0700 Mark Millard wrote: > [I'm adding a reference to an old arm64/aarch64 bug that had > pages turning to zero, in case this 32-bit powerpc issue is > somewhat analogous.] > > On 2020-May-13, at 00:29, Mark Millard wrote: > > > [stress alone is sufficient to have jemalloc asserts fail > > in stress, no need for a multi-socket G4 either. No need > > to involve nfsd, mountd, rpcbind or the like. This is not > > a claim that I know all the problems to be the same, just > > that a jemalloc reported failure in this simpler context > > happens and zeroed pages are involved.] > > > > Reminder: head -r360311 based context. > > > > > > First I show a single CPU/core PowerMac G4 context failing > > in stress. (I actually did this later, but it is the > > simpler context.) I simply moved the media from the > > 2-socket G4 to this slower, single-cpu/core one. > > > > cpu0: Motorola PowerPC 7400 revision 2.9, 466.42 MHz > > cpu0: Features 9c000000 > > cpu0: HID0 8094c0a4 > > real memory = 1577857024 (1504 MB) > > avail memory = 1527508992 (1456 MB) > > > > # stress -m 1 --vm-bytes 1792M > > stress: info: [1024] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd > > : > > /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258: > > Failed assertion: "slab == extent_slab_get(extent)" stress: FAIL: > > [1024] (415) <-- worker 1025 got signal 6 stress: WARN: [1024] > > (417) now reaping child worker processes stress: FAIL: [1024] (451) > > failed run completed in 243s > > > > (Note: 1792 is the biggest it allowed with M.) > > > > The following still pages in and out and fails: > > > > # stress -m 1 --vm-bytes 1290M > > stress: info: [1163] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd > > : > > /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258: > > Failed assertion: "slab == extent_slab_get(extent)" . . . > > > > By contrast, the following had no problem for as > > long as I let it run --and did not page in or out: > > > > # stress -m 1 --vm-bytes 1280M > > stress: info: [1181] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd > > ... > The following is was a fix for a "pages magically > turn into zeros" problem on amd64/aarch64. The > original 32-bit powerpc context did not seem a > match to me --but the stress test behavior that > I've just observed seems closer from an > external-test point of view: swapping is involved. > > My be this will suggest something to someone that > knows what they are doing. > > (Note: dsl-only.net closed down, so the E-mail > address reference is no longer valid.) > > Author: kib > Date: Mon Apr 10 15:32:26 2017 > New Revision: 316679 > URL: > https://svnweb.freebsd.org/changeset/base/316679 > > > Log: > Do not lose dirty bits for removing PROT_WRITE on arm64. > > Arm64 pmap interprets accessed writable ptes as modified, since > ARMv8.0 does not track Dirty Bit Modifier in hardware. If writable > bit is removed, page must be marked as dirty for MI VM. > > This change is most important for COW, where fork caused losing > content of the dirty pages which were not yet scanned by pagedaemon. > > Reviewed by: alc, andrew > Reported and tested by: Mark Millard > PR: 217138, 217239 > Sponsored by: The FreeBSD Foundation > MFC after: 2 weeks > > Modified: > head/sys/arm64/arm64/pmap.c > > Modified: head/sys/arm64/arm64/pmap.c > ============================================================================== > --- head/sys/arm64/arm64/pmap.c Mon Apr 10 12:35:58 > 2017 (r316678) +++ head/sys/arm64/arm64/pmap.c Mon Apr > 10 15:32:26 2017 (r316679) @@ -2481,6 +2481,11 @@ > pmap_protect(pmap_t pmap, vm_offset_t sv sva += L3_SIZE) { > l3 = pmap_load(l3p); > if (pmap_l3_valid(l3)) { > + if ((l3 & ATTR_SW_MANAGED) && > + pmap_page_dirty(l3)) { > + > vm_page_dirty(PHYS_TO_VM_PAGE(l3 & > + ~ATTR_MASK)); > + } > pmap_set(l3p, ATTR_AP(ATTR_AP_RO)); > PTE_SYNC(l3p); > /* XXX: Use pmap_invalidate_range */ > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > Thanks for this reference. I took a quick look at the 3 pmap implementations we have (haven't check the new radix pmap yet), and it looks like only mmu_oea.c (32-bit AIM pmap, for G3 and G4) is missing vm_page_dirty() calls in its pmap_protect() implementation, analogous to the change you posted right above. Given this, I think it's safe to say that this missing piece is necessary. We'll work on a fix for this; looking at moea64_protect(), there may be additional work needed to support this as well, so it may take a few days. - Justin