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

[Cliff Frey]

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?

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
>