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

Wed Oct 5 13:43:37 EDT 2011

Hi Roman,

On Wed, Oct 5, 2011 at 7:30 PM, rchertov <rchertov at cs.ucsb.edu> wrote:
> 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);

I don't use ToDevice. My config is that I fetch packets from a
FromDevice and then drop them immediately with a SimpleIdle element.

So that's why I _don't do_ an xmit. I assume that this config
combination works fine, since the system runs stable on a high packet
rate.

Thanks,
Daniel

> 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
>>>
>>>
>
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

-- 
Web: http://gnumaniacs.org