search for: valloc

Hi Richard, On 11/25/2013 04:50 PM, Richard Yao wrote: > I figured out the problem. There is zerocopy IO is being done via DMA to > a buffer allocated with valloc(). Right now, I am running a hack-fix > locally so I can get some other stuff done first. I will propose a > proper fix to the list in a few days. I've also encountered this issue on a non-QEMU simulator and have been carrying a disable-zero-copy hack for a few months. Let me know if the...

Hi Richard, On 11/25/2013 04:50 PM, Richard Yao wrote: > I figured out the problem. There is zerocopy IO is being done via DMA to > a buffer allocated with valloc(). Right now, I am running a hack-fix > locally so I can get some other stuff done first. I will propose a > proper fix to the list in a few days. I've also encountered this issue on a non-QEMU simulator and have been carrying a disable-zero-copy hack for a few months. Let me know if the...

Christopher, It sounds like you disabled zero-copy entirely, which is not necessary. As far as I recall, loading kernel modules is the only case in which valloc() allocated buffers are used. In the worst case, we only need to disable zero-copy on such buffers. I have been using a small patch to do precisely that since yesterday. I have attached it to this email since it sounds like the first version might be helpful to others while I take the time to explo...

...(CallInst *CI = dyn_cast<CallInst>(X)) if (Function *F = CI->getCalledFunction()) if (F->isName("free") && F->hasExternalLinkage()) return true; return false; } There is no need to have an actual IR object for it. posix_memalign, calloc, valloc and others are all great reasons why we shouldn't have a MallocInst either. -Chris

On Jan 11, 2009, at 11:22 AM, Chris Lattner wrote: >>> There is no good reason for malloc to be an instruction anymore. >>> I'd >>> be very happy if it got removed. Even if we keep it, malloc/alloca >>> should be extended to optionally take 64-bit sizes. >> >> I'm curious. Do we want to keep the free instruction? > > No,

Hi, > On Fri, 2011-04-29 at 09:05 +0200, Peter J. Philipp wrote: >> You don't check for malloc failure. I've made a patch that is possibly >> wrong but it saves the program from SIGSEGV and replaces it with SIGABRT. On Fri, 29 Apr 2011, Philipp Schafft wrote: > But I have a question: > Not all of them (only had a brief look at the patch) look to be in a >

...rite 5k at a time this is extremly slow, check it out with Solaris truss. Use sockets with large I/O or shared memory on the same system. To see the difference try timex dd if=xyz of=lll bs=5k vs timex dd if=xyz of=lll bs=1024k 3. When allocating memory which will be accessed all the time use valloc() which is memalign(sysconf(_SC_PAGESIZE),size) It aligns memory to the page, so memory copies are word/page align and therefore faster, ie. 4 bytes are copied at once instead of a byte at once. 4. If you use GigaBit ethernet to get performance you need to read/write 64Kbytes to the socket and le...

...nl https://lists.fedoraproject.org/archives/list/glibc at lists.fedoraproject.org/thread/WJHGG2OO7ABNAYICGA5WQZ2Q34Q2FEHU/ >> AC_CHECK_FUNCS([\ >> posix_fadvise \ >> posix_memalign \ >> + prctl \ >> strerrordesc_np \ >> valloc]) > > AC_CHECK_FUNCS looks for whether the given entry point can be linked > with, which is okay for functions in the common headers (<stdlib.h>, > <unistd.h>, ...) that autoconf includes in its test programs by > default. But... > >> >> diff --git a/lib/t...

Hola, I am trying to isolate the memory leak I suspect in a mailman installation ? I found: http://blogs.sun.com/sanjeevb/date/200506 It gives an error: god at irt-smtp-02:~ 9:21am 65 # ./memleak.d 10312 dtrace: failed to compile script ./memleak.d: line 3: probe description pid10312:libc.so.1:malloc:entry does not match any probes I am on SunOS 5.10 Generic_127112-07 i86pc i386 i86pc Are

...28:Call KERNEL.15: GLOBALALLOC(0002,00009100) ret=05ef:004f ds=02a7 0820ac28:trace:global:GLOBAL_Alloc 37120 flags=0002 0820ac28:trace:virtual:NtAllocateVirtualMemory 0x41120000 00010000 1000 00000040 0820ac28:trace:virtual:VIRTUAL_SetProt 0x41120000-0x4112ffff c-rWx View: 0x410f0000 - 0x411fffff (valloc) 0x410f0000 - 0x4112ffff c-rWx 0x41130000 - 0x411fffff ----- 0820ac28:trace:global:GlobalHandle16 0137 0820ac28:Ret KERNEL.15: GLOBALALLOC() retval=083e ret=05ef:004f ds=02a7 0820ac28:trace:global:GlobalHandle16 0137 0820ac28:Call KERNEL.18: GLOBALLOCK(083e) ret=05ef:005d ds=02a7 0820a...

...AllocateVirtualMemory (nil) 00110000 2000 00000040 View: 0x551d0000 - 0x552dffff (anonymous) 0x551d0000 - 0x552dffff --rwx 0009:trace:virtual:NtAllocateVirtualMemory 0x551d0000 00010000 1000 00000040 0009:trace:virtual:VIRTUAL_SetProt 0x551d0000-0x551dffff c-rwx View: 0x551d0000 - 0x552dffff (valloc) 0x551d0000 - 0x551dffff c-rwx 0x551e0000 - 0x552dffff --rwx 0009:trace:heap:RtlAllocateHeap (0x551d0000,00000002,00000018): returning 551d0098 0009:trace:heap:RtlAllocateHeap (0x551d0000,00000002,00000050): returning 551d00b8 0009:trace:heap:RtlAllocateHeap (0x551d0000,00000002,0000001...

...g. > When memory is running out, malloc() may return a valid pointer, but > writing anything in the malloc-ed data region can still result in the > kernel killing the process. Hmm.. So what am I not reading right in this: "If successful, calloc(), malloc(), realloc(), reallocf(), and valloc() functions return a pointer to allocated memory. If there is an error, they return a NULL pointer and set errno" Running out of memory is not considered as an error when calling malloc? Romain

...compile problems on some UNIX systems. In order to fix these compile problems on as wide a range of systems as possible, I'd appreciate it if people could send me the man pages for the following functions on their systems. These functions are : vsnprintf getpagesize sysconf memalign mprotect valloc People with the following systems need not send man pages, as the Samba Team already has access to these and we will check ourselves : SGI IRIX (all versions). Sun Solaris (versions 2.4 or above). Linux (all versions) FreeBSD (all versions) When sending the man pages please remember to mention w...

"Ogg Vorbis uses the Ogg bistream format, and the correct extension is .ogg" -- http://www.xiph.org/ogg/vorbis/faq.html I'm guessing it should read 'bitstream'. <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org'

...mean "llvm.free" or something, right? I don't think we want to start assigning meaning to otherwise arbitrary function names. Nick > return true; > return false; > } > > There is no need to have an actual IR object for it. posix_memalign, > calloc, valloc and others are all great reasons why we shouldn't have > a MallocInst either. > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/...

I figured out the problem. There is zerocopy IO is being done via DMA to a buffer allocated with valloc(). Right now, I am running a hack-fix locally so I can get some other stuff done first. I will propose a proper fix to the list in a few days. On 11/25/2013 10:49 AM, Richard Yao wrote: > I booted a Gentoo Linux installation in QEMU with a 9P rootfs as follows: > > sudo qemu-kvm -cpu hos...

Wim, Below are two problems I found in testing the newly released ocfs version. Just for your information. Gr, Robert. - Copying of multiple files gives errors [oracle@prac01 test]$ cp --o_direct -R ./a2/* ./backup/a2/. cp: writing `./backup/a2/./ccdata.dbf.bck': Invalid argument cp: writing `./backup/a2/./ccindex.dbf': Invalid argument cp: writing `./backup/a2/./control02.ctl':

On Mon, Oct 03, 2016 at 02:43:03PM +0200, Michael Kruse via llvm-dev wrote: > 2016-10-03 13:55 GMT+02:00 Martin J. O'Riordan via llvm-dev > <llvm-dev at lists.llvm.org>: > > I am trying to implement some new alignment based optimisations in our > > target backend, and I am wondering if there a way a target can specify that > > ‘malloc’, ‘realloc’ and ‘calloc’

...'t say for certain that it will. This particular error is caused by the fact that the run-time does not know which allocator is best for allocating page-aligned sections of memory. If you modify getPages() in runtime/BitmapPoolAllocator/PageManager.cpp to use mmap(), posix_memalign(), or valloc(), then it will fix this error and allow you to continue experimenting with Poolalloc/SAFECode in 64-bit mode. Eventually, we should set up something in the configure script to find a usable default for this function. This would be a simple autoconf change; it just hasn't been high on the...

....org/archives/list/glibc at lists.fedoraproject.org/thread/WJHGG2OO7ABNAYICGA5WQZ2Q34Q2FEHU/ > >> AC_CHECK_FUNCS([\ > >> posix_fadvise \ > >> posix_memalign \ > >> + prctl \ > >> strerrordesc_np \ > >> valloc]) > > > > AC_CHECK_FUNCS looks for whether the given entry point can be linked > > with, which is okay for functions in the common headers (<stdlib.h>, > > <unistd.h>, ...) that autoconf includes in its test programs by > > default. But... > > > &...