[Click] Queue Memory Allocation: vmalloc or kmalloc

[Latency Buster]

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