Date: Tue, 19 Jun 2018 13:10:15 -0600 From: Warner Losh <imp@bsdimp.com> To: bob prohaska <fbsd@www.zefox.net> Cc: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.cn85.dnsmgr.net>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: GPT vs MBR for swap devices Message-ID: <CANCZdfr97LhcFwOXp8n0N=Bb2=Y_zt2%2BUN%2B8dudQT1mJLVOFCg@mail.gmail.com> In-Reply-To: <CANCZdfoNasSpvEN-y3bzsDfWT=_atfp62AKvdpwK8bUQKi=bgA@mail.gmail.com> References: <20180614175622.GC35161@www.zefox.net> <201806142110.w5ELAL0N046840@pdx.rh.CN85.dnsmgr.net> <20180615035225.GA37370@www.zefox.net> <CANCZdfoNasSpvEN-y3bzsDfWT=_atfp62AKvdpwK8bUQKi=bgA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 14, 2018 at 10:00 PM, Warner Losh <imp@bsdimp.com> wrote: > > > On Thu, Jun 14, 2018, 9:52 PM bob prohaska <fbsd@www.zefox.net> wrote: > >> On Thu, Jun 14, 2018 at 02:10:21PM -0700, Rodney W. Grimes wrote: >> > >> > It might be interesting to do in order the swapon >> > commands to 1G USB flash, 1G SD flash, 2G SD flash, >> >> It seems clear that USB flash swap, alone or in any >> combination, fails early in buildworld. > > > I think that's because USB flash can't swap fast enough to keep up with > the page demand. You might be able to confirm this by looking at the write > rates to the swap portions for the various other media with gstat. I > suspect it's FTL is doing more expensive garbage collection under a swap > work load leading to long pauses from time to time that the VM system > responds to by starting OOM too soon. > Looking at the data posted, I see that we have a 2s latency averaged over 10s. This means that the drive is basically unresponsive. So the average latency is 2s. That means that the max latency is likely way more than that (likely as much as 10-20s if my experience with SSD latency distributions can be trusted). The latency bounces around a bit (and there appears to be some missing data), but this is what I expected to see. Now, maybe we have an issue with the USB stack that's causing this (missed interrupts leading to polling 'saving' the day after a massively long time, for example), or the USB drives are as bad as I've experiences them to be. In any event, if we can't retire the dirty pages fast enough, we'll get into OOM to try to cope with too many dirty pages. The different control loops in the system to moderate these things have some 'hidden' assumptions that we can launder pages faster than this, so I think we're falling off the rails when we can't, even when we have available swap space. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr97LhcFwOXp8n0N=Bb2=Y_zt2%2BUN%2B8dudQT1mJLVOFCg>