From owner-freebsd-arm@freebsd.org Tue Jun 19 01:35:41 2018 Return-Path: Delivered-To: freebsd-arm@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 2CC81100F54A for ; Tue, 19 Jun 2018 01:35:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-28.consmr.mail.bf2.yahoo.com (sonic317-28.consmr.mail.bf2.yahoo.com [74.6.129.83]) (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 A908C800BA for ; Tue, 19 Jun 2018 01:35:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ywC3BkIVM1lAfFGp_CCwymM9WiGEI4s1VNboTzPfFZhoor4QvYgUygK0EtmlaZK bJXjn__m5Un_lqUF8ND6judyKnyhucMM6HdXCTYU7NkYlTP7y3cOUy5GduWI0uYUdUpcBUdFP6HL zO7VVyNnoyOzbHDp.ic9LFAwNE1fEEWUolFnyDTnFz4AIUBjRewkMhjRSt.WJoUZecgWxXpX1Paw msAOdzI_5i7iQdZh12Ipga86s9vrUjDmY2i0lejmkI3._uV_fyjmcj_n.1tdI0rSZvPRSEWEP_Pp P6tW2GsX64TACkbd6dbjc19VAR00BQ6UGPVyfTT6wAA8oho8cbGm4WVmcDDkta45zz4H.e8C7RvA va4Oz97q3_vgqjCUZ4mbl_OhKoCPLHV5FmSMlWO9FMUVWU7f.fyjywJCwRg4XLO0y1zbxgVsuNlr EiUaNdDFypf7XH4CQMmRfrc6EndlYZhz_T7gYoCa8OPHWrbZOu4Aj.96uLb8zNAS9Phxb5LeXv5i qnAKNCSfvfvyNZP5eVs7eDrEjXn6.qC7neltx6lc4I8MykR.NWqCORiB2xmCwiOnG9aqDMvtpUva 3UeeESXYSRKAOyVc8Crq_1jBmznwHk04lz5wre2zU9xJzIR5Jq.yTpTE1cTd7zo4DSqUUm5iLfDc IzaH.dRcyMG1x7Hbiqx_0rqIWV4kM7EepkY.XNevNw2iJOFRlZh6kxpct872mLNn8Ou5OaTmblAh oZquNZgz1.eZf0x9mycOJhF9v3d0qzEi8R1mM2aOxcqeRBAS_sA2tGmwP7NJnHMlm3m29jzQcr83 NdqKTqSkfSS.WUq_jeP9qleq1yMPyZ3MlVhzxW4MKVewS8p._uezH33jZ7XcE39GvwINWx4q1Hdh 3VLakxDcAToIgxHNqkr0zH3Ae.AUoLl39fzjEGJiObux0l.GSvnVZBr2.TXaj0K9N21tTp0u9fyd K3D1a6g-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Tue, 19 Jun 2018 01:35:33 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp429.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID db0d6207771e9698dd880c4300b50e2e; Tue, 19 Jun 2018 01:35:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: GPT vs MBR for swap devices From: Mark Millard In-Reply-To: Date: Mon, 18 Jun 2018 18:35:29 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180618230419.GA81275@www.zefox.net> <20180619005519.GB81275@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 01:35:41 -0000 On 2018-Jun-18, at 6:31 PM, Mark Millard wrote: > On 2018-Jun-18, at 5:55 PM, bob prohaska = wrote: >=20 >> On Mon, Jun 18, 2018 at 04:42:21PM -0700, Mark Millard wrote: >>>=20 >>>=20 >>> On 2018-Jun-18, at 4:04 PM, bob prohaska = wrote: >>>=20 >>>> On Sat, Jun 16, 2018 at 04:03:06PM -0700, Mark Millard wrote: >>>>>=20 >>>>> Since the "multiple swap partitions across multiple >>>>> devices" context (my description) is what has problems, >>>>> it would be interesting to see swapinfo information >>>>> from around the time frame of the failures: how much is >>>>> used vs. available on each swap partition? Is only one >>>>> being (significantly) used? The small one (1 GiByte)? >>>>>=20 >>>> There are some preliminary observations at >>>>=20 >>>> = http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbusbflash_1gbsdflash_= swapinfo/1gbusbflash_1gbsdflash_swapinfo.log >>>>=20 >>>> If you search for 09:44: (the time of the OOM kills) it looks like >>>> both swap partitions are equally used, but only 8% full. >>>>=20 >>>> At this point I'm wondering if the gstat interval (presently 10 = seconds) >>>> might well be shortened and the ten second sleep eliminated. On the = runs >>>> that succeed swap usage changes little in twenty seconds, but the = failures >>>> seem to to culminate rather briskly. >>>=20 >>> One thing I find interesting somewhat before the OOM activity is >>> the 12355 ms/w and 12318 ms/w on da0 and da0d that goes along >>> with having 46 or 33 L(q) and large %busy figures in the same >>> lines --and 0 w/s on every line: >>>=20 >>> Mon Jun 18 09:42:05 PDT 2018 >>> Device 1K-blocks Used Avail Capacity >>> /dev/da0b 1048576 3412 1045164 0% >>> /dev/mmcsd0s3b 1048576 3508 1045068 0% >>> Total 2097152 6920 2090232 0% >>> dT: 10.043s 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 0 0 0 0.0 0 9 10.8 0 0 = 0.0 0.1 mmcsd0 >>> 46 0 0 0 0.0 0 16 12355 0 0 = 0.0 85.9 da0 >>> 0 0 0 0 0.0 0 9 10.8 0 0 = 0.0 0.1 mmcsd0s3 >>> 0 0 0 0 0.0 0 9 10.8 0 0 = 0.0 0.1 mmcsd0s3a >>> 33 0 0 0 0.0 0 22 12318 0 0 = 0.0 114.1 da0d >>> Mon Jun 18 09:42:25 PDT 2018 >>> Device 1K-blocks Used Avail Capacity >>> /dev/da0b 1048576 3412 1045164 0% >>> /dev/mmcsd0s3b 1048576 3508 1045068 0% >>> Total 2097152 6920 2090232 0% >>>=20 >>>=20 >>> The kBps figures for the writes are not very big above. >>>=20 >>=20 >> If it takes 12 seconds to write, I can understand the swapper getting = impatient.... >> However, the delay is on /usr, not swap. >>=20 >> In the subsequent 1 GB USB flash-alone test case at >> = http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbusbflash_swapinfo/1g= busbflash_swapinfo.log >> the worst-case seems to be at time 13:45:00 >>=20 >> dT: 13.298s 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 0 0 0 0.0 0 5 5.5 0 0 = 0.0 0.1 mmcsd0 >> 9 84 0 0 0.0 84 1237 59.6 0 0 = 0.0 94.1 da0 >> 0 0 0 0 0.0 0 5 5.5 0 0 = 0.0 0.1 mmcsd0s3 >> 0 0 0 0 0.0 0 5 5.6 0 0 = 0.0 0.1 mmcsd0s3a >> 5 80 0 0 0.0 80 1235 47.2 0 0 = 0.0 94.1 da0b >> 4 0 0 0 0.0 0 1 88.1 0 0 = 0.0 0.7 da0d >> Mon Jun 18 13:45:00 PDT 2018 >> Device 1K-blocks Used Avail Capacity >> /dev/da0b 1048576 22872 1025704 2% >>=20 >> 1.2 MB/s writing to swap seems not too shabby, hardly reason to kill = a process. >=20 > That is kBps instead of ms/w. >=20 > I see a ms/w (and ms/r) that is fairly large (but notably > smaller than the ms/w of over 12000): >=20 > Mon Jun 18 13:12:58 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/da0b 1048576 0 1048576 0% > dT: 10.400s 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 4 0 0 0.0 4 66 3.4 0 0 = 0.0 1.3 mmcsd0 > 8 18 1 32 1991 17 938 2529 0 0 = 0.0 88.1 da0 > 0 4 0 0 0.0 4 63 3.5 0 0 = 0.0 1.3 mmcsd0s3 > 0 4 0 0 0.0 4 63 3.5 0 0 = 0.0 1.3 mmcsd0s3a > 6 11 1 32 1991 10 938 3207 0 0 = 0.0 94.7 da0d > Mon Jun 18 13:13:19 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/da0b 1048576 0 1048576 0% >=20 >=20 > Going in a different direction, I believe that you have > reported needing more than 1 GiByte of swap space so the > 1048576 "1K-blocks" would not be expected to be sufficient. > So the specific failing point may well be odd but the build > would not be expected to finish without an OOM for this > context if I understand right. >=20 >> Thus far I'm baffled. Any suggestions? >=20 > Can you get a failure without involving da0, the drive that is > sometimes showing these huge ms/w (and ms/r) figures? (This question > presumes having sufficient swap space, so, say, 1.5 GiByte or more > total.) >=20 > Having the partition(s) each be sufficiently sized but for which > the total would not produce the notice for too large of a swap > space was my original "additional" suggestion. I still want to > see what such does as a variation of a failing context. But now > it would seem to be a good idea to avoid da0 and its sometimes > large ms/w and /ms/r figures. >=20 One more point: I'd suggest avoiding da0 for holding any log files or other such files that are being updated and used: Avoid da0 as much as possible, not just its swap partition(s). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)