Thanks for all the pointers and suggestions! On Thu, Jul 1, 2010 at 6:05 PM, Cliff Frey <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> >> > 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, <[email protected]> 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 <[email protected]> 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 >> >> >> [email protected] >> >> >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> >> > >> >> > >> >> >> >> _______________________________________________ >> >> click mailing list >> >> [email protected] >> >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> > >> > > >
_______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
