[Click] insmod: error inserting '/usr/local/lib/click.ko': -1 Cannot allocate memory

[Eddie Kohler]

Hi Daniel,

I'm curious about the FromDevice element's highwater_length.  This is 
the maximum length of its internal packet queue.  I *just* committed a 
change that will let you track this value via a handler.  If the value 
is 1, then your theory is right, and FromDevice is rescheduling the 
Click kernel module immediately, which is bumping out the rest of the 
softirq processing.  If the value is more than 1, we need another theory.

Eddie



On 10/5/11 1:23 PM, Daniel Borkmann wrote:
> Hi Cliff,
>
> On Wed, Oct 5, 2011 at 7:15 PM, Cliff Frey<cliff at meraki.com>  wrote:
>> You could try adding BURST 10 or something to your FromDevice configuration
>> and see if that makes a difference.
>> You could also try changing tasks_per_iter (there is a top level handler, so
>> you could add "Script(write tasks_per_iter 300)" to your config).
>> I don't actually think that either of the above will make much difference...
>> as I believe that the click task should currently try and send 128 packets
>> each time it is scheduled (tasks_per_iter * BURST == 128 * 1 == 128).
>>   However, the BURST one is definitely worth trying.
>> You could also try changing the "weight" on your ethernet driver, but that
>> also should default to 64 or higher, so I don't understand how/why so few
>> packets would be processed each time.
>> If you run ifconfig after the test, are there any error counters that are
>> very high?
>
> Thanks for the hints.
>
> No, there aren't any error values on the NIC driver. If I turn off
> click (click-uninstall), then the packet rate rises up to approx 1,38
> Mio pps (receive and drop by the kernel) and the context switch rate
> decreases to less than 1000 per sec. I tried the whole experiment
> multiple times - each time the same as described. Is the click kernel
> thread running in high-priority or RT mode? This could maybe explain
> the starvation of the ksoftirqd.
>
> Thanks,
> Daniel
>
>> Cliff
>> On Wed, Oct 5, 2011 at 8:58 AM, Daniel Borkmann<borkmann at iogearbox.net>
>> wrote:
>>>
>>> On Wed, Oct 5, 2011 at 4:06 PM, Eddie Kohler<kohler at cs.ucla.edu>  wrote:
>>>> I'm thinking probably we should do that automatically.
>>>
>>> Hmm, if someone wants to do debugging, then it might not work (since
>>> the syms are stripped), except you have a special target for debug,
>>> for instance.
>>>
>>> What I recently noticed running Click in kernelspace: the number of
>>> context switches per second is very high (... too high) on a high
>>> packet rate. More details:
>>>
>>> I have two machines Intel Core 2 Quad Q6600 CPU, 4 GB RAM, Intel
>>> 82566DC Ethernet Controller (e1000e driver). Both have Debian 6.0. One
>>> machine has a vanilla Linux 3.0 running pktgen with 64 Byte packets
>>> (max. load), the other one is running Linux 2.6.38 with click in
>>> kernelspace. Both are directly connected. The config is:
>>> source::FromDevice(eth0); drop::SimpleIdle; source->drop. I was
>>> measuring packets per second and the system's context switches per
>>> second, both gathered from procfs. The result was that I reached about
>>> 460k pps while having a context switch rate of about 200k cs/sec (!).
>>> (The high rate explains the rather low pps rate.) Running
>>> (multithreaded) click in userspace on top of Linux 3.0, I got about
>>> 545k pps and less than 1000 cs/sec.
>>>
>>> Has anyone measured similar values? Could it be, that the click kernel
>>> thread is pushing away CPU time for the ksoftirqd doing NAPI (sofirqs
>>> for RX) on the e1000e?
>>>
>>> Thanks,
>>> Daniel
>>>
>>>>
>>>> Eddie
>>>>
>>>> On 10/5/11 9:32 AM, Daniel Borkmann wrote:
>>>>>
>>>>> Hi Sandeep,
>>>>>
>>>>> thanks for your reply! :-)
>>>>>
>>>>> Stripping the debug symbols out of the module like ...
>>>>>
>>>>> root at xyz:~# strip -g /usr/local/lib/click.ko
>>>>>
>>>>> ... worked for me; I already was on the latest Git repository.
>>>>>
>>>>> Thanks,
>>>>> Daniel
>>>>>
>>>>> On Wed, Oct 5, 2011 at 3:14 PM, sandeep<sandeep048 at gmail.com>    wrote:
>>>>>>
>>>>>> I also had the same problem but it disappeared after I updated to the
>>>>>> latest
>>>>>> git repository. https://github.com/kohler/click/tarball/master
>>>>>>
>>>>>> Kind Regards,
>>>>>> Sandeep,
>>>>>> PhD Student,
>>>>>> CTVR - Trinity College Dublin
>>>>>> On Wed, Oct 5, 2011 at 1:36 PM, Daniel
>>>>>> Borkmann<borkmann at iogearbox.net>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi list,
>>>>>>> I managed to build the patchless Click kernel version under 2.6.38,
>>>>>>> but insmod fails with the following:
>>>>>>>
>>>>>>> root at pc-10089:~# click-install forw.click
>>>>>>> insmod: error inserting '/usr/local/lib/click.ko': -1 Cannot allocate
>>>>>>> memory
>>>>>>> click-install: '/sbin/insmod /usr/local/lib/click.ko' failed
>>>>>>>
>>>>>>> Any ideas? Did anyone have same issues?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Daniel
>>>>>>> _______________________________________________
>>>>>>> click mailing list
>>>>>>> click at amsterdam.lcs.mit.edu
>>>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Web: http://gnumaniacs.org
>>>
>>> _______________________________________________
>>> click mailing list
>>> click at amsterdam.lcs.mit.edu
>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>
>>
>
>
>