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
