headers
Latency Buster | 1 Jul 2010 21:44
Picon

Queue Memory Allocation: vmalloc or kmalloc

I have a machine with 32GB Ram... I am testing a scenario to find out
how long a burst can click handle based on varying service rate. If I
make the incoming queue length = 1.5 million packets, will click
allocate the memory using kmalloc or vmalloc? Since I have a machine
with large ram (32GB), I was thinking of allocating 2GB for packet
queues. Is that feasible with the current version of Click?

Thanks,
Permalink | Reply | 7 comments |
headers
rchertov | 1 Jul 2010 22:00
Picon

Re: Queue Memory Allocation: vmalloc or kmalloc

Not sure on the largest size array that you can allocate in Click, but if
the Queue element complains about the size, you should be able to just link
the packets back to back using "next" defined in the Packet class.  That
will require making a custom element, but it should do the trick.

Roman

On 12:44 pm 07/01/10 Latency Buster <latencybuster <at> gmail.com> wrote:
> I have a machine with 32GB Ram... I am testing a scenario to find out
> how long a burst can click handle based on varying service rate. If I
> make the incoming queue length = 1.5 million packets, will click
> allocate the memory using kmalloc or vmalloc? Since I have a machine
> with large ram (32GB), I was thinking of allocating 2GB for packet
> queues. Is that feasible with the current version of Click?
> 
> Thanks,
> _______________________________________________
> click mailing list
> click <at> amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
Permalink | Reply | 6 comments |
headers
Latency Buster | 1 Jul 2010 22:42
Picon

Re: Queue Memory Allocation: vmalloc or kmalloc

Thanks.. The 'problem' is that I am not able to find out whether the
queue  element is storing the packets via vmalloc or kmalloc. I
observed that after 700,000 packets (for my system), y the drain rate
of the queue is decreasing rapidly under constant service rate...

Also, do I need to use ThreadSafeQueue for a multicore system? There
is only one producer pushing into the queue and only one consumer..
But both the producer and consumer elements have been mapped to
different cores.

On Thu, Jul 1, 2010 at 4:00 PM,  <rchertov <at> cs.ucsb.edu> wrote:
> Not sure on the largest size array that you can allocate in Click, but if
> the Queue element complains about the size, you should be able to just link
> the packets back to back using "next" defined in the Packet class.  That
> will require making a custom element, but it should do the trick.
>
> Roman
>
> On 12:44 pm 07/01/10 Latency Buster <latencybuster <at> gmail.com> wrote:
>> I have a machine with 32GB Ram... I am testing a scenario to find out
>> how long a burst can click handle based on varying service rate. If I
>> make the incoming queue length = 1.5 million packets, will click
>> allocate the memory using kmalloc or vmalloc? Since I have a machine
>> with large ram (32GB), I was thinking of allocating 2GB for packet
>> queues. Is that feasible with the current version of Click?
>>
>> Thanks,
>> _______________________________________________
>> click mailing list
>> click <at> amsterdam.lcs.mit.edu
(Continue reading)

Permalink | Reply | 5 comments |
headers
Cliff Frey | 1 Jul 2010 23:01
Favicon

Re: Queue Memory Allocation: vmalloc or kmalloc

if you look at click/lib/glue.cc at the implementation of click_lalloc, you
can see that it will use vmalloc for allocations that are larger than 128kb,
so that would be queue size of 32k for 32 bit machines, or 16k for 64 bit
machines.

I don't believe that ThreadSafeQueue is necessary as long as you have only
one producer and one consumer.

Also, this probably isn't necessary to say, but I really hope that you have
compiled a 64 bit kernel.  All packet memory has to be mapped into the
kernel's virtual address space, so if you want more than ~1-2GB of packet
memory allocated allocated at the same time, you *must* be using a 64 bit
architecture (not just using PAE).

Cliff

On Thu, Jul 1, 2010 at 1:42 PM, Latency Buster <latencybuster <at> gmail.com>wrote:

> Thanks.. The 'problem' is that I am not able to find out whether the
> queue  element is storing the packets via vmalloc or kmalloc. I
> observed that after 700,000 packets (for my system), y the drain rate
> of the queue is decreasing rapidly under constant service rate...
>
> Also, do I need to use ThreadSafeQueue for a multicore system? There
> is only one producer pushing into the queue and only one consumer..
> But both the producer and consumer elements have been mapped to
> different cores.
>
> On Thu, Jul 1, 2010 at 4:00 PM,  <rchertov <at> cs.ucsb.edu> wrote:
> > Not sure on the largest size array that you can allocate in Click, but if
(Continue reading)

Permalink | Reply | 3 comments |
headers
rchertov | 1 Jul 2010 23:08
Picon

Re: Queue Memory Allocation: vmalloc or kmalloc

Typically, the packets are created when the Packet::make is called and an
skb is allocated.  The queue just keeps a track of pointers to the Packet
objects.  The skbmanager is used to deal with the packet buffers
themselves.  It might be that there is a problem with the skbmanager, when
there are that many packets at once.

ThreadSafeQueue appears to be a good choice for what you are doing.

On 1:42 pm 07/01/10 Latency Buster <latencybuster <at> gmail.com> wrote:
> Thanks.. The 'problem' is that I am not able to find out whether the
> queue  element is storing the packets via vmalloc or kmalloc. I
> observed that after 700,000 packets (for my system), y the drain rate
> of the queue is decreasing rapidly under constant service rate...
> 
> Also, do I need to use ThreadSafeQueue for a multicore system? There
> is only one producer pushing into the queue and only one consumer..
> But both the producer and consumer elements have been mapped to
> different cores.
> 
> On Thu, Jul 1, 2010 at 4:00 PM,  <rchertov <at> cs.ucsb.edu> wrote:
> > Not sure on the largest size array that you can allocate in Click,
> > but if the Queue element complains about the size, you should be able
> > to just link the packets back to back using "next" defined in the
> > Packet class.  That will require making a custom element, but it
> > should do the trick.
> >
> > Roman
> >
> > On 12:44 pm 07/01/10 Latency Buster <latencybuster <at> gmail.com> wrote:
> >> I have a machine with 32GB Ram... I am testing a scenario to find out
(Continue reading)

Permalink | Reply | 0 comments |
headers
Latency Buster | 1 Jul 2010 23:50
Picon

Re: Queue Memory Allocation: vmalloc or kmalloc

Yes.. I am using a 64bit architecture with 64bit kernel.. if I change
the value of
# define CLICK_LALLOC_MAX_SMALL 131072
 to

# define CLICK_LALLOC_MAX_SMALL  999999

and it's a 64bit kernel, do we expect a problem here?

Thanks,

On Thu, Jul 1, 2010 at 5:01 PM, Cliff Frey <cliff <at> meraki.com> wrote:
> if you look at click/lib/glue.cc at the implementation of click_lalloc, you
> can see that it will use vmalloc for allocations that are larger than 128kb,
> so that would be queue size of 32k for 32 bit machines, or 16k for 64 bit
> machines.
> I don't believe that ThreadSafeQueue is necessary as long as you have only
> one producer and one consumer.
> Also, this probably isn't necessary to say, but I really hope that you have
> compiled a 64 bit kernel.  All packet memory has to be mapped into the
> kernel's virtual address space, so if you want more than ~1-2GB of packet
> memory allocated allocated at the same time, you *must* be using a 64 bit
> architecture (not just using PAE).
> Cliff
>
> On Thu, Jul 1, 2010 at 1:42 PM, Latency Buster <latencybuster <at> gmail.com>
> wrote:
>>
>> Thanks.. The 'problem' is that I am not able to find out whether the
>> queue  element is storing the packets via vmalloc or kmalloc. I
(Continue reading)

Permalink | Reply | 2 comments |
headers
Cliff Frey | 2 Jul 2010 00:05
Favicon

Re: Queue Memory Allocation: vmalloc or kmalloc

That will likely work, but it depends on your kernel configuration and the
largest size that kmalloc is allowed to allocate.  Also, I really wouldn't
expect any noticable performance difference between vmalloc-allocated memory
and kalloc-allocated memory.

You can look at linux/include/linux/kmalloc_sizes.h from your linux headers
for more information about the maximum size that kmalloc can allocate...

Cliff

On Thu, Jul 1, 2010 at 2:50 PM, Latency Buster <latencybuster <at> gmail.com>wrote:

> Yes.. I am using a 64bit architecture with 64bit kernel.. if I change
> the value of
> # define CLICK_LALLOC_MAX_SMALL 131072
>  to
>
> # define CLICK_LALLOC_MAX_SMALL  999999
>
> and it's a 64bit kernel, do we expect a problem here?
>
> Thanks,
>
>
>
> On Thu, Jul 1, 2010 at 5:01 PM, Cliff Frey <cliff <at> meraki.com> wrote:
> > if you look at click/lib/glue.cc at the implementation of click_lalloc,
> you
> > can see that it will use vmalloc for allocations that are larger than
> 128kb,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Latency Buster | 2 Jul 2010 00:09
Picon

Re: Queue Memory Allocation: vmalloc or kmalloc

Thanks for all the pointers and suggestions!

On Thu, Jul 1, 2010 at 6:05 PM, Cliff Frey <cliff <at> meraki.com> wrote:
> That will likely work, but it depends on your kernel configuration and the
> largest size that kmalloc is allowed to allocate.  Also, I really wouldn't
> expect any noticable performance difference between vmalloc-allocated memory
> and kalloc-allocated memory.
> You can look at linux/include/linux/kmalloc_sizes.h from your linux headers
> for more information about the maximum size that kmalloc can allocate...
> Cliff
>
> On Thu, Jul 1, 2010 at 2:50 PM, Latency Buster <latencybuster <at> gmail.com>
> wrote:
>>
>> Yes.. I am using a 64bit architecture with 64bit kernel.. if I change
>> the value of
>> # define CLICK_LALLOC_MAX_SMALL 131072
>>  to
>>
>> # define CLICK_LALLOC_MAX_SMALL  999999
>>
>> and it's a 64bit kernel, do we expect a problem here?
>>
>> Thanks,
>>
>>
>>
>> On Thu, Jul 1, 2010 at 5:01 PM, Cliff Frey <cliff <at> meraki.com> wrote:
>> > if you look at click/lib/glue.cc at the implementation of click_lalloc,
>> > you
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ricard Vilalta | 6 Jul 2010 12:34
Picon

Re: The most asked question

Hi all,
I am looking for an answer to this question. Has anyone succeeded in 
patching a linux kernel greater than 2.6.24.7 ?
Thanks in advance,
Ricard

On 06/02/2010 06:55 PM, Dishko Georgiev wrote:
> Hi all,
>
> I have followed Click for some time, but recently i decided to
> actually use it. But machine that i've got for it, only run with newer
> kernels, 2.6.24 does not support X58 chipsets and also latest Intel
> e1000e cards.
> So i started patching all sort of kernels with 0 luck ( i mean
> manually patching). Non of kernels are working properly.
> After hard digging in mail list archives, i saw that many ppls talk
> about 2.6.31 kernels, but no1 actually uploaded patches for it.
> So, my questions is: does any1 work on patching lastest kernels and if
> some1 have working patch, pls send me a copy, tnx.
> Also, i thing patchless linuxmodule will have no success, becouse of
> non standard coding of linux kernel, u actualy wont be able to fully
> cover all changes u need to compile with C++ compiler.
>
> Tnx in advance, Julian
> _______________________________________________
> click mailing list
> click <at> amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
rchertov | 6 Jul 2010 17:25
Picon

Re: The most asked question

On 3:34 am 07/06/10 Ricard Vilalta <ricard.vilalta <at> cttc.es> wrote:
> Hi all,
> I am looking for an answer to this question. Has anyone succeeded in 
> patching a linux kernel greater than 2.6.24.7 ?

http://pdos.csail.mit.edu/pipermail/click/2009-September/008290.html

I am not sure how many people tested this though.  If you don't plan to use
the e1000 polling driver, I recommend you try the patchless way.  You can
search the archives on how to do this.

Roman

> Thanks in advance,
> Ricard
> 
> On 06/02/2010 06:55 PM, Dishko Georgiev wrote:
> > Hi all,
> >
> > I have followed Click for some time, but recently i decided to
> > actually use it. But machine that i've got for it, only run with newer
> > kernels, 2.6.24 does not support X58 chipsets and also latest Intel
> > e1000e cards.
> > So i started patching all sort of kernels with 0 luck ( i mean
> > manually patching). Non of kernels are working properly.
> > After hard digging in mail list archives, i saw that many ppls talk
> > about 2.6.31 kernels, but no1 actually uploaded patches for it.
> > So, my questions is: does any1 work on patching lastest kernels and if
> > some1 have working patch, pls send me a copy, tnx.
> > Also, i thing patchless linuxmodule will have no success, becouse of
(Continue reading)

Permalink | Reply | 0 comments |

Gmane