This control is used to define the rough relative IO cost of swapping and filesystem paging, as a value between 0 and 200. At 100, the VM assumes equal IO cost and will thus apply memory pressure to the page cache and swap-backed pages equally; lower values signify more expensive swap IO, higher values indicates cheaper.
另外是設定 0 時的方式，在不夠用的時候還是會去用：
At 0, the kernel will not initiate swap until the amount of free and file-backed pages is less than the high watermark in a zone.
We can see that performance stabilizes after a bit at around 20K QPS, with some 380MB/sec disk IO and 125MB/sec swap IO. The 95% query response time has grown to around 9ms.
當拉到 48GB 的時候就更掉更多，6K QPS 與 35ms (95%)：
Now we have around 6K QPS. Disk IO has dropped to 250MB/sec, and swap IO is up to 190MB/sec. The 95% query response time is around 35ms.
作者發現掉的比率沒有想像中大：
When I started, I expected severe performance drop even with very minor swapping. I surprised myself by getting swap activity to more than 100MB/sec, with performance “only” halved.
這邊測試用的是 SSD，如果是傳統用磁頭的硬碟，對 random access 應該會很敏感而掉更多：
This assumes your swap space is on an SSD, of course! SSDs handle random IO (which is what paging activity usually is) much better than HDDs.
基本上還是要避免碰到 swap 啦，另外 comment 的地方剛好有提到前陣子在猜測的 best practice，測試時的 vm.swappiness 是設成 1，這應該是作者的 best practice：
Swappiness was set to 1 in this case. I was not expecting this to cause significant impact as swapping is caused by genuine (intended) missconfiguration with more memory required than available.
This control is used to define how aggressive the kernel will swap memory pages. Higher values will increase agressiveness, lower values decrease the amount of swap. A value of 0 instructs the kernel not to initiate swap until the amount of free and file-backed pages is less than the high water mark in a zone.
