Try it on the new Kernel :-) many things have changed like in the 2.6.13
*******************************************************************
PGP Fingerprint: 6695 794A B84E D922 88FB 73CC 6CBD 8036 B3CD 7304
We can't become what we need to be by remaining what we are
*******************************************************************
Nagendra Singh Tomar wrote:
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
-
: 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
