RPI3 swap experiments (grace under pressure)

[Jedi Tek'Unum]

On Aug 14, 2018, at 11:26 PM, Warner Losh <imp at bsdimp.com> wrote:
> 
> So I think what's well tuned for the gear that's in a server doing
> traditional database and/or compute workloads may not be so well tuned for
> the RPi3 when you put NAND that can vary a lot in performance, as well as
> have fast reads and slow writes when the mix isn't that high. The system
> can be tuned to cope, but isn't tuned that way out of the box.

When there are no-win situations due to restrictive hardware then the best solution is likely documentation encouraging people to avoid such hardware.

I doubt this is worth the effort of developing a kludge as one would expect that these limitations will go away as hardware evolves - rapidly.

If people want to do things like -j4 on this kind of hardware then they are asking for trouble.

Might as well recommend swap over nfs. Surely not something one would recommend on normal hardware but in this case it probably isn’t any worse than slow NAND.

However, I remain of the opinion that when people try to use hardware unable to achieve minimal behavior that they should just suffer the unresponsiveness. Surely thresholds can be recognized and warning syslog messages provided. I’d rather have it sluggish than dying at random times.


I’ve not looked at OOM details on FreeBSD… Is there a special signal sent to the victim before its killed? A quick glance at the signal list says no. Of course that would introduce even more complexity as the victim would need some reprieve time to be able to do something with it. Even AIX had this in the ‘80s. My experience back then was that it was better than nothing but not terribly useful.