Hi all, Linux TCP stack tracks system wide memory resource using the sysctl_tcp_mem[3] array. Out of these, sysctl_tcp_mem[2] is the upper limit which is expected to be the total system memory resource that all TCP sockets combined can use (both for Tx as well as Rx purposes) This is filled once in tcp_init(), using a heuristical method which approximately gives 75% of total RAM to sysctl_tcp_mem[2]. This variable (along with sysctl_tcp_mem[0] and sysctl_tcp_mem[1]) is checked, every time TCP allocates memory (in tcp_mem_schedule()) to check the memory pressure in the system. If the total tcp_memory_allocated increases beyond sysctl_tcp_mem[2] tcp_mem_schedule() even suppresses allocation. Good so far. My observation is that, if there is heavy memory allocation afterwards (in my setup one application allocates 200MB of the available 500 odd MB), the tcp_init() calculation which was done keeping 500MB free memory in mind, no longer holds good and the TCP system wide ceiling check (along with sysctl_tcp_mem[0] and sysctl_tcp_mem[1]), kind of, lose their meaning. The checks always pass thus not adding any value to the system. My question is. Why are we not dynamically changing these values, based on the current allocations (updated in alloc_pages() and free_pages()) ? This way we can control the incoming data for all connections more realistically and more promptly than as we do with static settings. My ref is kernel version 2.4.23, but I think things are not very much different in 2.6.x also. Thanx, Tomar -- You have moved the mouse. Windows must be restarted for the changes to take effect. - : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
