I've been trying out a raspi 3 as a desktop recently, and have run into strange performance problems, particularly when using chrome.


  • raspberry pi 3
  • running raspbian stretch
  • 2.5A power supply
  • "fake kms" opengl driver selected
  • 256MB allocated to video RAM
  • swap files disabled
  • swappiness set to either 1 or 0

The issue I'm seeing is that, with a few tabs open in chromium, the system gets into a certain characteristic state:

  • UI becomes extremely unresponsive
  • kswapd typically at 10% CPU
  • top reports wait time around 50%, with user and sys at 1 to 5%
  • about 200MB free memory in top

I've read reports about how systems behave when there is no swap and the system is running out of ram (kswapd goes crazy and the system grinds to a halt).

That seems to match how my system is behaving, but I have 200MB free! wtf?

I'm also suspicious of that 200MB number -- it seems to be staying suspiciously consistent at 200MB, even if I try to e.g. open another blank tab (which takes several minutes).

Is there some kernel parameter which is telling the system how much free RAM to keep available?

Is there a way I can tell the system to just use the OOM killer instead of going nuts with kswapd? I'd rather see hard evidence (a killed process) that I'm actually "running out RAM" (despite 200MB reported free).


p.s. the performance problems seem specific to the chromium workload. Running Quake 1 at 800x600 with opengl runs very smooth with no issues.

  • Why did you disable swap? Disabling it can cause problems if you don't have a pretty deep knowledge of what you're doing and this appears to be one of them.
    – T. M.
    Commented Feb 23, 2019 at 2:00
  • Thanks T.M., but I'm looking for answers which are a bit more constructive than "don't do that". If I enable swap, I still have the same problem -- the machine slows down (starts swapping) once it reaches 200MB free. Commented Feb 24, 2019 at 2:37
  • That's very different information than what was included in your question. You should edit your question to state that you had this problem with swap enabled, then tried disabling it and had the same problem.
    – T. M.
    Commented Feb 24, 2019 at 10:22
  • No, it's the same information: the system refuses to dip into the last 200MB of free memory. Whether I have swap enabled is just a distraction. Commented Feb 26, 2019 at 2:06

1 Answer 1


I would recommend enabling swap in the form of zram, which should give you much more graceful degradation than you're seeing. My guess is that the kernel is trying to keep you from oomkiller by repeatedly paging out text segments, which then have to be brought back in to execute. Better to execute at all than kill things, in the kernel's opinion.

Also, make sure that you don't have a gpu_mem= setting in config.txt -- unless you're using the camera or accelerated video decode (in w, that memory is just being wasted.

  • Thanks Eric, disabling swap was simply one of the steps in tracking down this performance issue (initially, the system was clearly exhibiting "thrashing" like performance issues when I had swap enabled, yet it still had about 200MB of free memory. Disabling swap seems to have proven that there is something which is causing the kernel to attempt to never dip below the 200MB free RAM threshold. I've replicated a similar setup on a typical x86 linux box and didn't see this strange behavior near the 200MB threshold. I think my next step is to try a non-raspbian kernel). Commented Feb 24, 2019 at 2:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.