See this Stackoverflow article, specifically the cat /proc/buddyinfo command. For example on my NAS with 16GB RAM:
root@…:~# cat /proc/buddyinfo
Node 0, zone DMA 0 0 0 0 0 0 0 0 1 2 2
Node 0, zone DMA32 3272 18652 7369 2570 625 33 1 0 0 0 0
Node 0, zone Normal 6557 9962 14916 8801 4556 1531 64 16 3 7 0
Each column represents contiguous free chunks of size 2ⁿ bytes, starting from 4kiB on the leftmost column, ending at 4MiB on the rightmost column. You can see that my node has no free 4MiB chunks, 7 chunks of size 2MiB etc.
It’s bad if right-most of the columns are zeros. How many of them need to be non-zero, that depends on hardware and software. kswapd gets hyperactive when an allocation for a large contiguous chunk fails. Usually software does not require contiguous chunks, but hardware drivers or options like large pages sometimes need them. So, let say, if your hardware drivers like allocating 64kiB buffers, then at least the fifth column should be nonzero. Though, figuring out what allocations are needed in your specific case seem to be somewhat difficult, I didn’t bother.
vm.min_free_kbytes helps in the sense that it tries to keep some amounts RAM free both from software allocations and buffers/cache, so there’s higher chance that a large chunk of contiguous free memory is available. As such, it is a dirty workaround, but it’s good enough for me. It is set on my NAS to 1048576, that is, 1 GiB, and I’ve mostly stopped seeing kswapd taking any nontrivial CPU time. What number is right for you, you will need to figure out on your own.