From owner-freebsd-ppc@freebsd.org Tue Mar 5 03:43:14 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 492DC150EE86 for ; Tue, 5 Mar 2019 03:43:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-21.consmr.mail.ne1.yahoo.com (sonic316-21.consmr.mail.ne1.yahoo.com [66.163.187.147]) (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 53D777467C for ; Tue, 5 Mar 2019 03:43:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: o5oIhPkVM1mMEt6LbSlq7NxZGZu0AHjxITDCEVH0.LOwXOw75sfmL9WzjuHBTWu Y_g2b.mzPgvMMz8_lfasPSmf5ZCqTW0_He_KpI.CrktFG241w6wwFAnOYbfZAes12PSGKYj24ZCU yLChdDPzs0YkWa3DHkb5wlHSyvK4CrvFpQ6MifJCw0s5aqbHX_joeiY5cogERECO.qLN3fXYhCB_ P_JHjGKfotvb7Avf6.X0em9CMVltseEtigQC78doao9ce1mlTkGAmwxlJvHRTgvpEqbUZfZaHrL8 2ixJEoeDAjCR0iT0oN0UFkSS4vi.N5ZX_Avo5oyGp.GHxFAJ5V9rrXtXvphnM0oru3RrS6c9dRY_ pc1N.RXMmHvSH7f9p5vg4zxEhku8j57SMHlDRC8BUDN3SSjBrA7ZTFYL3K52VhUjoC50_jVt7S9X aDkuRwV6X2iQs6L89zEqJgc2la9_Tp_u5_A73UHGDvIfxx0R1aVmk5gg3oeeOBpuwSDKL9Ygm3rQ aFD1VgCRqD.xqt6FoFk.bOZDuZPbKn_hUuiz3SYPHzthBaoDmVuPCL7ONcTKDni.sOgtHKOku3Wk Q69F4Mgc_HSHuX7htrmT_yswRdF69Z8FFv7A5u7rlxPelDY8DCU4TzcCyRDOL8kdbRmD7DV4Akng z7e_sCrCwy34TGVdArm9RXaEfrkRrVbv5FENEPbQFGZlK3q1M60TMj4J2cTErISlpL779nu3LcZ5 KfKMhxWyxePPk4An7y2vtd40.x_YUT4Pw9VQrwvSS7.tA7sX35H2gUSckxpDxRVXaY51ExbN2WwV IOm_.PHECYzRWgJo5HBPTtggr2lTv8JFz6JmGBaNVTHnES1Dv55QcQX1CvQ9gRaTl3ShxxOwfOid 4mmIyAaGD8bJCn3jqOSll_1vEYb9sivik1t2i6hyymLe3ePZnjaoreGjdCq4MiU5CFUdOiLDgFtU bLNqTR41.8N1w8Qfs4AuccTXwmnnX.BNK2ZE.M5VEPXiwxmvc7QXPen6Ch1r.xII.RnADkCDJwLT gsOWKZNsUaV0Jef7pSnPaZPwDetShUED.k4S6KDAoyk2Oob0- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Tue, 5 Mar 2019 03:43:11 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp424.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID aced078fc5d192f968d617b862f84c56 for ; Tue, 05 Mar 2019 03:43:11 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: head -r344018 powerpc64 variant on Powermac G5 (2 sockets, 2 cores each): [*buffer arena] shows up more . . .? Message-Id: Date: Mon, 4 Mar 2019 19:43:09 -0800 To: FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 53D777467C X-Spamd-Bar: ++++ X-Spamd-Result: default: False [4.19 / 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]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.98)[0.985,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ppc@freebsd.org]; NEURAL_SPAM_MEDIUM(0.86)[0.857,0]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_LONG(0.90)[0.901,0]; RCVD_IN_DNSWL_NONE(0.00)[147.187.163.66.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.95)[ip: (2.58), ipnet: 66.163.184.0/21(1.26), asn: 36646(1.00), country: US(-0.07)] 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: Tue, 05 Mar 2019 03:43:14 -0000 [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=3D1 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?) /usr/src/sys/vm/vm_init.c has: /* * Allocate the buffer arena. * * Enable the quantum cache if we have more than 4 cpus. This * avoids lock contention at the expense of some fragmentation. */ size =3D (long)nbuf * BKVASIZE; kmi->buffer_sva =3D firstaddr; kmi->buffer_eva =3D kmi->buffer_sva + size; vmem_init(buffer_arena, "buffer arena", kmi->buffer_sva, size, PAGE_SIZE, (mp_ncpus > 4) ? BKVASIZE * 8 : 0, 0); firstaddr +=3D size; I wonder if the use of "BKVASIZE * 8" should track the bufspacedeamon-* thread count and not just the mp_cpus count --or if the bufspacedeamon-* thread count should track the mp_ncpus count (and so be smaller for only 4 "cpus" in FreeBSD terms.) Or may be [*buffer arena] is inherent in having: (Not from the time frame of having the [*buffer arena] showing up, not even from after such. I've not managed to see such figures during and I've not recorded any after.) real memory =3D 17134088192 (16340 MB) avail memory =3D 16385716224 (15626 MB) hw.physmem: 17134088192 hw.usermem: 15232425984 hw.realmem: 17134088192 Virtual Memory: (Total: 455052K Active: 413888K) Real Memory: (Total: 64736K Active: 62508K) Shared Virtual Memory: (Total: 56264K Active: 15232K) Shared Real Memory: (Total: 16416K Active: 14204K) Free Memory: 14022736K vm.kmem_size: 5482692608 vm.kmem_zmax: 65536 vm.kmem_size_min: 12582912 vm.kmem_size_max: 13743895347 vm.kmem_size_scale: 3 vm.kmem_map_size: 414158848 vm.kmem_map_free: 5068533760 vfs.bufspace: 1397690368 vfs.bufkvaspace: 559185920 vfs.bufmallocspace: 0 vfs.bufspacethresh: 1680538825 vfs.buffreekvacnt: 1007 vfs.bufdefragcnt: 0 vfs.buf_pager_relbuf: 0 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)