Hi Stephen,
Your change to track the maximum failed allocation looks helpful, as
this will focus extra swap attention when a problem actually occurs. So
assuming that the client has a retry capability (as with NFS), it should
improve recoverability.
One possible downside is that kswapd infinite looping may become more
likely, as we still have no way to determine when the memory
configuration makes it impossible to achieve the memory goal. I still
see this "swap deadlock" in 110 (and all recent kernels) under low
memory or by doing a swapoff. Any ideas on how to best determine an
infeasible memory configuration?
Under some conditions the most helpful action may be to let some
allocations fail, to shed load or kill processes. (But selecting the
right process to kill may not be easy ...)
Regards,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html