[Click] About memory allocation

Beyers Cronje bcronje at gmail.com
Tue Nov 14 08:46:10 EST 2006


Hi Guido,

As a start I would recommend you upgrade to CVS version of Click. Some
memory problem fixes is in CVS that's not in 1.5.0, the main one that
springs to mind is the skb Recycling bug fix. Let us know how it goes.

Cheers

Beyers Cronje

On 11/14/06, Guido Alejandro Gavilanes <ggavilanes at gmail.com> wrote:
>
> Hello Eddie and all developers which make this project a very useful
> tool for research!!
>
> I have been working on a switch prototype using click (1.5.0) using
> ethernet encapsulation and forwarding between 2 interfaces on a host.
> Trying with some ellaborated configurations (after having tried a bit
> with click elements functionality), I began to perform some gross
> testing with certain amount of packets per second, and then some
> problem started to appear...
>
> - I am using 6000 packets/sec on one interface and going out from the
> second interface. Packets are pings and are generated by a tester
> machine with two NICs. Those pings generate a throughput of 18Mbps
> according to my tester. This traffic is unidirectional and just
> forwarded by my click device.
>
> - internally I use an Etherswitch to enable the host to perform
> learning and use some other interfaces later. It is running on Kernel
> mode and not running anything else or elements different from the
> distribution.
>
> - in this test, The host running the click configuration runs out of
> memory in a matter of few seconds, more or less it looses 3Mbytes of
> memory per second (I tested this using command cat /proc/meminfo  ->
> MemFree  information). In the console, it appears this message
>
> " __alloc_pages: 0-order allocation failed (gfp=0x...)",
>
> then it starts killing processes and finally crashes, having to
> reboot, or putting a script to monitor memory and shutting down click
> when a limit is reached. I have seen on linux pages this is certainly
> a memory problem, but anyway after unloading click module, memory is
> not freed.
>
> - When I replaced the etherswitch element with another void internally
> hard-connected element (due to the fact etherswitch is experimental),
> it also looses memory at a lower rate, (more or less 3KBytes/sec) with
> the same packet rate described above. (I tested it for 1000 seconds
> and noted the continuously decreasing memory)
>
> - The same occurs by just replacing this configuration by a simpler
> one, just receiving from an eth interface and putting through an
> output queue to the other interface.
>
> - I searched in the mailing lists, but I dont see "memory leaks"
> problems (in fact just one
> https://amsterdam.lcs.mit.edu/pipermail/click/2006-June/005022.html),
> and that's why I guess my problem may require your attention.
>
> -> The host machine I am using is a pentium 3, @800 MHz, 128MBytes in
> RAM, Swap  256.
> -> Operating System: Red Hat 9.0, running a kernel downloaded from
> www.kernel.org ( version 2.4.32) and patched accordingly to click
> instructions.
>
> Ok, this is the problem, I would like to read some ideas around it,
> and Thank you in advance for any additional information!
>
> Guido
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>


More information about the click mailing list