Update README.md

README.md

@@ -256,11 +256,17 @@ aes-128-cfb     847216.79k   850770.86k   853712.05k   859912.39k   854565.80k
 The encrytion performance in kcptun is as fast as in openssl library(if not faster).
 
 
-#### Memory Usage Control
+#### Memory Control
 
 Routers, mobile devices are susceptible to memory consumption; by setting GOGC environment(eg: GOGC=20) will make the garbage collector to recycle faster.
 Reference: https://blog.golang.org/go15gc
 
+Primary memory allocation are done from a global buffer pool *xmit.Buf*, in kcp-go, when we need to allocate some bytes, we can get from that pool, and a *fixed-capacity* 1500 bytes(mtuLimit) will be returned, the *rx queue*, *tx queue* and *fec queue* all gets bytes from there, and they will return the bytes to the pool after use to prevent *unnecessary zer0ing* of bytes. 
+The pool mechanism maintained a *high watermark* for slice objects, these *in-flight* objects got from the pool will survive from the perodical garbage collection, meanwhile the pool kept the ability to return the memory to runtime if in idle, `-sndwnd`,`-rcvwnd`,`-ds`, `-ps`, these parameters affects this *high watermark*, the larger the value, the bigger the memory consumption will be.
+
+`-smuxbuf` also affects the maximum memory consumption, this parameter maintains a subtle balance between *concurrency* and *resource*, you can increase this value(default 4MB) to boost concurrency if you have many clients to serve and you got a powerful server at the same time, and also you can decrease this value to serve only 1 or 2 clients and hope this program can run under some embeded SoC system with limited memory and only you can access. (Notice that the `-smuxbuf` value is not proprotional to concurrency, you need to test.)
+
+
 #### Compression
 
 kcptun has builtin snappy algorithms for compressing streams: