UserAgent: Mozilla/5.0 (X11; CrOS armv7l 9202.64.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.146 Safari/537.36
Platform: 9202.64.0 (Official Build) stable-channel daisy_spring

Steps to reproduce the problem:
1. Have HP Chromebook 11 G1 at default tests.
2. Open Youtube video (h.264 480p) and browse the web until (z)swap gets used.
3. Notice slowdowns on the interface of software like the Youtube HTML5 player.
4. Turn /dev/zram0 swap off.
5. Youtube is now responsive, can pause, resume and go forward/backward on the video without interface stalls or delays. Activity on swap usage can be seen as this happens.

What is the expected behavior?
Swap on ZRAM should not slow down the machine. Upon disabling ZSWAP manually, everything is working as expected: the OOM killer is triggered much more often but everything works fine. Only minor slowdowns are experienced when the OOM needs to kill tabs. This is much better behavior than on regular Linux desktop, where lack of swap and free RAM will result in OOM lockups.

What went wrong?
It seems that the ZRAM module may be using more than 1 thread, so what I assume is higher priority from 2 kernel threads for 2 cores is starving the user space threads. Not sure of the underlying mechanism or how the 'zram' module is loaded, as a way to confirm if 1 thread for ZRAM would alleviate this issue.

Did this work before? No 

Chrome version: 57.0.2987.146  Channel: stable
OS Version: 9202.64.0
Flash Version: Shockwave Flash 25.0 r0

Youtube gets extremely unresponsive even though I'm running HW decoding through the use of the "h.264ify" extension - VP9 will be much harder on the CPU.
I've been running without ZSWAP for a couple of years now and turning it back on today was quite the bad experience. Most users experiencing this will probably replace the machine even though it is still quite decent when running no ZSWAP.