From owner-freebsd-ppc@freebsd.org Thu Mar 7 00:39:43 2019 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 361DF152CB2C for ; Thu, 7 Mar 2019 00:39:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-22.consmr.mail.ne1.yahoo.com (sonic303-22.consmr.mail.ne1.yahoo.com [66.163.188.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 74C4F80FED for ; Thu, 7 Mar 2019 00:39:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: zu8mKcgVM1lK5W0KqjY4NncAhmEnGjNw8C_14mD.UYNaemmLh3v22Q4adXvu6So 9MFnjesOW2Xxls4ona3pUZ5zA0o8Vu893P.S2f8SEysMuHN9ZAFMMKwvbMI3_q2IYxyPDAenAC.F yFLqkOWRvxVL5A.JaZaeaEz.r5bclhcbXWKnEbSUUnUPNfRzz3PNMc0CWamUV19Ebx1eIy_wdwyq 9XpeNFxj9tjqqyulM1l9G48Z5ZWXE72Krt3JEJ2QUoP99ZYj88mHZ6wHb8e0PKdCz_ndxNhp0ogd DAxwYV7q9BJYHbhzEyW0YcY6Up..uFUD38ckoGURG6r5PP6CBYNOtrj8ZxnCfiPgZQR3SiHOis4s OChAchFCXApEPhKkZE2YcA5O480EpjcBrj1rXP1QPBxvfWBHAMm_k6BcvSMlP7LXPCsQawT3DtBb pTFclWqFnc7BeAEAeiPZbEZekKDK4qdhJJbTNodMDAZn0shoIywJyTH0gTbIz5rgiziePht8GGSq qQLmkR5tGQL5ZvyaEVBJ_c22Jsm8MLbe.CULV7nYp0__mymcsHg.Cw2a_8N1lhTwHjYlmd3ld0zB xdBMg3MiUUtyevlmuHyW1ARP0dN7jopeQ_jtYNB47SgxR4Ak5_Y54iNw8Lx.y2XU6KFUQZUCg37P 02ZF3DTgTTVd2NMI43he_3qqb7.AggZicYZmhWKtoyGXgXIyfkCVGycRoYAP9QZwEicf.1zB08Jg wqAHXIKC2kDhfP45h5uSF2ia27GVprm8wWJ1DzRGfp5IGNBv4ahO60S7mjrutXMS84nRswxJLzJc Ds_sl80Pw_Bg3R_QpiSm21StXVGl9lD.7qdn_.nW4.1HuUug7heUTGy5FTdR0FkFW6t98_I2jHsU mP2nY1UikwxHsE5JxydamjK7jvfxwuvG6Btd03ScxS4CZ5oO07ceG8rZGGYZpvTUMdFj18oxZ2Wv nq5LdHYna4nvGGurK9I0cnrZRSqpOZS3qzxkajEiTvJBiU5PF1NEfmjbhCy0Rb0MP4VpedMTuKRY DeEB9sMKHpfnamRQY_SlxsG4MKtwYjVkHm0SjW1po.9b0yi0ZRduE_VIh1HCHhCxspsy3cdxKXAz nEdym3w-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Thu, 7 Mar 2019 00:39:34 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.113]) ([67.170.167.181]) by smtp409.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0e675305e94033af7ef2499a82435e18; Thu, 07 Mar 2019 00:39:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: head -r344018 powerpc64 variant on Powermac G5 (2 sockets, 2 cores each): [*buffer arena] shows up more . . .? From: Mark Millard In-Reply-To: <20190306151914.44ea831c@titan.knownspace> Date: Wed, 6 Mar 2019 16:39:31 -0800 Cc: freebsd-ppc Content-Transfer-Encoding: 7bit Message-Id: <8668AAF7-9E6A-4278-9D1B-2ECDBD3804AA@yahoo.com> References: <20190306151914.44ea831c@titan.knownspace> To: Justin Hibbits X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 74C4F80FED X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.82 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; NEURAL_SPAM_SHORT(0.93)[0.927,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.93)[ip: (2.48), ipnet: 66.163.184.0/21(1.25), asn: 36646(1.00), country: US(-0.07)]; NEURAL_SPAM_MEDIUM(0.69)[0.686,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.78)[0.782,0]; RCVD_IN_DNSWL_NONE(0.00)[148.188.163.66.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[148.188.163.66.rep.mailspike.net : 127.0.0.17] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 00:39:43 -0000 On 2019-Mar-6, at 13:19, Justin Hibbits wrote: > On Mon, 4 Mar 2019 19:43:09 -0800 > Mark Millard via freebsd-ppc wrote: > >> [It is possible that the following is tied to my hack to >> avoid threads ending up stuck-sleeping. But I ask about >> an alternative that I see in the code.] >> >> Context: using the modern powerpc64 VM_MAX_KERNEL_ADDRESS >> and using usefdt=1 on an old Powermac G5 (2 sockets, 2 cores >> each). Hacks are in use to provide fairly reliable booting >> and to avoid threads getting stuck sleeping. >> >> Before the modern VM_MAX_KERNEL_ADDRESS figure there were only >> 2 or 3 bufspacedaemon-* threads as I remember. Now there are 8 >> (plus bufdaemon and its worker), for example: >> >> root 23 0.0 0.0 0 288 - DL 15:48 0:00.39 >> [bufdaemon/bufdaemon] root 23 0.0 0.0 0 288 - DL >> 15:48 0:00.05 [bufdaemon/bufspaced] root 23 0.0 >> 0.0 0 288 - DL 15:48 0:00.05 [bufdaemon/bufspaced] >> root 23 0.0 0.0 0 288 - DL 15:48 0:00.05 >> [bufdaemon/bufspaced] root 23 0.0 0.0 0 288 - DL >> 15:48 0:00.05 [bufdaemon/bufspaced] root 23 0.0 >> 0.0 0 288 - DL 15:48 0:00.05 [bufdaemon/bufspaced] >> root 23 0.0 0.0 0 288 - DL 15:48 0:00.07 >> [bufdaemon/bufspaced] root 23 0.0 0.0 0 288 - DL >> 15:48 0:00.05 [bufdaemon/bufspaced] root 23 0.0 >> 0.0 0 288 - DL 15:48 0:00.56 [bufdaemon// worker] >> >> I'm sometimes seeing processes showing [*buffer arena] that >> seemed to wait for a fairly long time with that status, not >> something I'd seen historically for those same types of >> processes for a similar overall load (not much). During such >> times trying to create processes to look around at what is >> going on seems to also wait. (Probably with the same status?) >> > > Hi Mark, > > Can you try the attached patch? It might be overkill in the > synchronization, and I might be using the wrong barriers to be > considered correct, but I think this should narrow the race down, and > synchronize the timebases to within a very small margin. The real > correct fix would be to suspend the timebase on all cores, which is > feasible (there's a GPIO for the G4s, and i2c for G5s), but that's a > non-trivial extra work. > > Be warned, I haven't tested it, I've only compiled it (I don't have a > G5 to test with anymore). > Sure, I'll try it when the G5 is again available: it is doing a time consuming build. I do see one possible oddity: tracing another platform_smp_timebase_sync use in the code . . . DEVMETHOD(cpufreq_drv_set, pmufreq_set) static int pmufreq_set(device_t dev, const struct cf_setting *set) { . . . error = pmu_set_speed(speed_sel); . . . } int pmu_set_speed(int low_speed) { . . . platform_sleep(); . . . } PLATFORMMETHOD(platform_sleep, powermac_sleep), void powermac_sleep(platform_t platform) { *(unsigned long *)0x80 = 0x100; cpu_sleep(); } void cpu_sleep() { . . . platform_smp_timebase_sync(timebase, 0); . . . } PLATFORMMETHOD(platform_smp_timebase_sync, powermac_smp_timebase_sync), The issue: I do not see any matching platform_smp_timebase_sync(timebase, 1) or other CPUs doing a powermac_smp_timebase_sync in this sequence. (If this makes testing the patch inappropriate, let me know.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)