GPT vs MBR for swap devices
imp at bsdimp.com
Tue Jun 19 19:10:18 UTC 2018
On Thu, Jun 14, 2018 at 10:00 PM, Warner Losh <imp at bsdimp.com> wrote:
> On Thu, Jun 14, 2018, 9:52 PM bob prohaska <fbsd at 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.
More information about the freebsd-arm