The idea might be the implementation is not.
Using a percentage to decide "almost out of memory" is going to hurt on
systems with large amounts of memory be it a 32gb desktop or a 2tb server.
You'd have plenty of memory left and it starts killing processes ...
And it will lead to the opposite problem on systems with lots of swap (e.g.,
my desktop PC that still follows the swap = 2 * RAM recommendation and hence
has 16 GiB of RAM and 32 GiB of swap): processes can do a lot of swap
thrashing in 32 * (1-10%) = 28.8 GiB of swap and still ruin the system
OOM handling really needs to use some interactivity metric, and I think this
can almost certainly be done reliably only in the kernel, because userspace
processes do not even get to run if the interactivity is already ruined.