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

rchertov rchertov at cs.ucsb.edu
Wed Oct 5 13:30:04 EDT 2011


Daniel,

Can you try running your config with undoing this update?
https://github.com/kohler/click/commit/d65bfe4054a23468c808e95df4ab6b4a5ef9d9a3
Change ret = dev_queue_xmit(skb1); to
        ret = dev->netdev_ops->ndo_start_xmit(skb1, dev);

This change will send the packet straight to the device driver.

Roman

On Wed, 5 Oct 2011 19:23:31 +0200, 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
>>
>>




More information about the click mailing list