From nobody Sun Sep 12 16:10:02 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1C04617BAE58 for ; Sun, 12 Sep 2021 16:10:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-21.consmr.mail.gq1.yahoo.com (sonic302-21.consmr.mail.gq1.yahoo.com [98.137.68.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 4H6vhh3TZ9z3QcC for ; Sun, 12 Sep 2021 16:10:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631463005; bh=k5iGyTqf43mIGhFWfXq0ZH2CSjG6vYCt1FdE7DTZjrQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=mZf3rALNVVnVDqguN4PJywDQIRVJG97Yv7HHZco42Hd64xe4xWhgIIRvp/WqN5m1Vb9NKK+tteW3/2L50g8vapNrVAO12zoVNqmpM3biCWq1G6C6jNWpQQDhmbL5sdIDAzCF3Tyk2+YWI5JdE5tyPYg18MnSH/R4c34bE5b1cRqrgAwJQjX6srn/Tw/cJEhizhXqMTZ46PLp7fyiD+bzq/MyTHKhP3sGc9YDfSQfDNrscg8tbNnFRW0MqQYoLdD2/+BdzcavBimH1pmSZHbSgueqXvp5diBaA1CyBPUn0jPfiZc0vJmjwgp+UOPF2uPnWALFOQFOTRPhYpVLTtgvkA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631463005; bh=pfCyawwEk3yJfrFgWBWue74qhcxCrRvDFRfgW2DgLKi=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=MAB6qZ8Ko9DFGjZZ1MRQOJsGgMgVltY6m8nb6oARQSK0QxR0z+iPaRA30GHFax5NaJSk2599CUt9m2pw9q2DgTOFtaS5QUuHyQ80pl3GAqXr+AL2e3BdSE4y+dGyMa31KEl+6Cg4uod/jQTlt9/iFcI+Z02i0FVvIXZjn5R3jambU3ssyYs8OyfOXDrtjCkKpd1dfCoEytFnYOyhTX5LMtSs4q4t9TkqMFu7D3ZbU0OhsxvHD/hNamBK1Gy6t1Yoa9VHLCHSvMNYb2cna4G8uwwtqoOD0v5J+vmI2aJDvYLRE5RH6u+Z1i8nG0suGfTgOC5oLxcPePaWcV7vw8wvAw== X-YMail-OSG: ULPVR30VM1nUlkyS.mkwapHkeQIkhERibq.oCwp2lwhyDzdDL4dpPmyGX4CSsVm vn7pEJcq7v3lt_mMpB_qeldCVbu.Z4d4dM1VpkmyxBN7a1nfysJuQsQ5PUVpCeDrcFknQDMDVlFl m2RGzwa3zBebl7fBoXfxUZ9tckpqrTDRjz67DTwkKFVaKUQPrv1tu5TTBIhXvbdjdFPgdtVoaL2u 1gr0CjoNSgliJs775yMluQT.CeUbqQulH0x4VTPqXj2NqnOu3s9WGNQMG64viTiRV.QE_pU_LLxh eMYAPsoMW0CjiqU.7eqSuvifDRkoo5t6KD2gnFpGTJ4bhBz1Sf9bBzeMg0NBJVlC9tCu89dfCPBt Xe8P.aRCnEreFU8.L_qO31eY_zcBy05SN_NpliVoiHJP_GMoj7sl87vKBbv7Nwq1y1eCzJAUItuj 7_joJrPH3ENvA2T4RH7G3kq9qeR03hJQ3I4pBQ76BtF1qEzKKUVg7OJNLut9TypmN9oVOyorY6Ht vAb0r7tBrPUReu0xZ91SjLfj4rKaGZ_WjwhZyjWyq_dfukf8QL3G.Lqxzx_AmbZFg0K2IT2HQs.r 3FMl1KCok5aeoCtGxF7TeCAX03.pNaNTr0IhA8tfEG0kwvSYCXqZrtorkWDzoCBk_U59bSpRM5Z. vGSPYc0i9mSyo9avumVJrRJe4rMDAnfblT34foff0fAg3XoH_fySHEhovTNrxf9R4ncxM8gRWm4N EChJH6a7VnRHI.E8kgMTNqfIQ4nuAWXN82FQc3lj3kQDSZJVL1.gZirw9t7TnIWHSAVhvqXyHVYn O1IEBNtt4hnqCubwobiXYa6aetGnDWOPr3z_fTEZWyE3uiim0e9thepEU9UC1YLiaImV4sF6hxA_ 3jxgm54WoCyeVVPS9o_DKiYr4.s4dufPQtRqteZVq7zpRLtCVKxW0xOBEgQ857Xh_8OiP15.0Yqb nKot6SSzGPR5j45c_pc8fh.YyO0woPEg8y6GFf7ebla7HXjbG.FtSGd5_WwCwvjx5JnVXALHecED 9nOV3FsHQlVNPWZF1YZLtYs4q6BV5SuW.KIzCrQulFZhWNlbZ8jVA0KntofOOVXoAaAOj3Jw8SPV IJWc1fxF0R66_T45JKWQ5nWh3NdQMZjRRlFGF4eRwZUatG.3CRsEPVyzQMnSjnOdKxzSkTR9c57p 9xePUMF23REk09GgwO8kxBuu9Yxobs6PyACbMXFl__7UOW2ZWbxIRonF9kMOOiXr.w0kZcaaQGFp G3FIr_wV07G.5v2o9YhKZI5MNy.RFtUUzLeFQ7en_zPYJ78W.kiJjdUg8HfKl3cQ2JPafkMpT8LP YoKFxeDe3T94hRMh8pMb_Vz_cqDwBadv_epGTdPrer5s.KBbWckySuJ4rFZxXQQgOWkPQw5LbOxV aUorCd9LovxQ.MtV29XG2gLFCUll9lA3j2ypgYR3iAHcM2cONkpj6qKeHMyDSCk9kPv950lP5M5T lO55vNoQbRtUPq7Rmv.wLajYCtOsNFGixD7GUVzjB5Xhb6QcRJ2Vk9qQIIsTcOhVXc9hzYmLgMGi DcwngsBRr5uXJxreqCKwJpJiqQt4bg4O_346NhulP2RzSxQgCQWbS.vVTk0afb6ZaxlcBJlGeAh6 cTmME4Kjel.R3OG8zG0zdSZb9g3nxYB4xZwv4v0X93PTJbpFxSybYKk4qGth0LJsCwN7X5wDryKH Tzb7JFnrsx1j7Mi201MyEn6WXrFZ6sKdvpRtCS3q5ZN38SH6JKqzJOe8ebd87kpRGN4YIk15xyq_ tDx8MEf_8ONo1RLFaF6G40ZSb92BqECxkJEn8VrrDLHtOixU6yugXLhP2Q5SLwVXk80VdyOycc4z lqXgTvQPTQ4Dnz7_nsE1YrVvEq7EzM9c2NFPp.Cqj.2dX.0ObwcZnr4VQsiFGyAG0oTk5JwkZff5 _nqrmHfYdR.TPaRCvFQh3rZfQPV.f4wKstDXtWMSHV.FQfc7_sXjO9hXxgusu8cpf5SwlS54litW _H1JFgJOdJxQ74tLqpsHxluS1birjjgSk4_G78yOkUj.62pAT1LYfCAkeBKbSg9_dFpHihOkYtNG vqeb0WdgNcJ2yZyBZ56uA.3aTIjdnw9kkaxCHjLOWVpZHy.6zf4aiA7vXRAOqfUvMN.RBdCcEWjD _CtBfhqhqTnNPgUTrdMV7ltPWIRjvFqRi5tDzFAnD.VUSgNQ.Q7.S0uQWR..l8cZOPs55zCbqBdr RcPj0mhRKjYP_FkPvPYKvDd.ovBb_vPKtQ_PrhQ_NYY2E3kpBu.VnmYSZFA47evtqRr4VGZyBdIH UD5LKs0znea9NA6gS.fk0qdNtZuW4dP4PcXKEYm8pnHerEalE3JRT1D9KFAl1Vg8of4r8 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Sep 2021 16:10:05 +0000 Received: by kubenode522.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c2e03098900df9d550c98009ecde6623; Sun, 12 Sep 2021 16:10:03 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Python2.7 seemingly stuck on RPI3 In-Reply-To: Date: Sun, 12 Sep 2021 09:10:02 -0700 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: References: To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4H6vhh3TZ9z3QcC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=mZf3rALN; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.147:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.147:from] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N [This is a resend now that I'm again subscribed to the freebsd-arm list.] From: bob prohaska =20 Date: Sat, 11 Sep 2021 12:34:40 -0700 : > A present attempt to compile www/chromium on a Pi3 using > a single make job has gotten stuck in a curious way:=20 >=20 > Python2.7 appears to be stuck, or nearly stuck, reading > swap. The machine isn't out of swap, in fact swap isn't > even very busy, around 85% for the hard disk partition=20 > and 15% for the microSD partition. Queue lengths are=20 > small and kBps close to 1000 for both.=20 >=20 >=20 > Here's a sample of disk activity: >=20 > procs memory page disks faults = cpu > r b w avm fre flt re pi po fr sr mm0 da0 in sy = cs us sy id > 0 0 13 2560404 57968 2546 103 83 35 2505 6020 0 0 20952 = 862 6525 19 4 78 > dT: 10.009s w: 10.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name > 0 147 147 944 0.9 0 0 0.0 0 0 = 0.0 13.6 mmcsd0 > 0 147 147 944 0.9 0 0 0.0 0 0 = 0.0 13.8 mmcsd0s2 > 1 144 141 878 6.6 2 76 31.8 0 0 = 0.0 85.9 da0 > 0 147 147 944 0.9 0 0 0.0 0 0 = 0.0 13.8 mmcsd0s2b > 1 143 141 878 6.6 2 76 31.8 0 0 = 0.0 86.0 da0s2 > 0 2 0 0 0.0 2 76 31.8 0 0 = 0.0 0.6 da0s2a > 1 141 141 878 6.6 0 0 0.0 0 0 = 0.0 86.0 da0s2b =46rom what is presented, I'd guess that da0s2b is on spinning rust. My expectation is that da0 is spending much of its time seeking and the system does not have much to do during the seek activity. So the sum of the latencies is adding significant time for any given amount of progress.=20 Be careful of interpreting %busy as I understand. But the 86.0 or so figures suggest not to expect getting much more. This all fits with the mmcsd0s2b activity for about the same use looking like could go faster. Note the 0.9 ms/r for mmcsd0 vs. the 6.6 ms/r for da0 as well as the < 15 figures for %busy for mmcsd0. Splitting the swapping/paging load across wildly mismatched media bottlenecks on the slower media for the interlaced accesses from what I can tell. Such a mismatch undoes any advantage from dual channels from what I can tell. Seek time is one of the reasons that I avoid spinning rust for machines that I do builds on (and more generally then that, but not universally). Fragmentation is less of an issue on the kinds of media that I use. For small arm boards I tend to use media that supports both USB2 and USB3 use, for example staying within power limits in each context but able to be fairly fast for USB3. I have access to Samsung Portable SSD T7 Touch 1TB's for such use in modern times. (I've not switched all the contexts over yet. The older type of media that I'd access to is not always purchasable these days --and is slower for making duplications as backups or the start of a small variations.) I've also been using T7's as alternate external boot media for bigger machines, such as being able to boot and operate any of: HoneyComb, MACCHIATObin Double Shot, RPI4B (8 GiByte) via the same external media. I make no claim that the T7's properties are unique for such issues. The T7's just happen to be what I've used. Handling the power issue as I want eliminates many products for me. (I avoid USB hubs when I can for the small arm boards.) > Sat Sep 11 12:01:49 PDT 2021 > Device 1K-blocks Used Avail Capacity > /dev/da0s2b 1843200 882800 960400 48% > /dev/mmcsd0s2b 1843200 880600 962600 48% > Total 3686400 1763400 1923000 48% >=20 > Here's a sample of top output >=20 >=20 > last pid: 41683; load averages: 0.04, 0.13, 0.15 = up 15+17:47:00 12:02:29 > 48 processes: 1 running, 47 sleeping > CPU: 0.1% user, 0.0% nice, 0.7% system, 0.7% interrupt, 98.5% idle > Mem: 429M Active, 23M Inact, 182M Laundry, 222M Wired, 87M Buf, 44M = Free > Swap: 3600M Total, 1711M Used, 1889M Free, 47% Inuse, 3784K In >=20 > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU = COMMAND > 24726 root 1 20 0 1566M 627M swread 1 7:36 1.83% = python2.7 > 1074 bob 1 20 0 14M 1100K CPU0 0 39:03 0.14% = top > 881 root 1 20 0 12M 268K select 0 6:49 0.02% = powerd > 1069 bob 1 20 0 20M 684K select 0 3:28 0.02% = sshd > 942 root 1 20 0 20M 644K select 3 3:18 0.00% = sshd > 24504 root 1 41 0 370M 356K select 2 1:17 0.00% = ninja > 945 root 1 20 0 17M 972K select 2 1:04 0.00% = sendmail > 827 root 1 20 0 13M 616K select 2 1:03 0.00% = syslogd >=20 > Admittedly, 1700M of swap is a lot in use, but in the past the machine > was able to work through much higher swap usage. Now it seems well and > truly stuck, though still reasonably responisve to keyboard input. > It's unclear to me if this is my error or something else. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)