Re: Reason for doing malloc / bzero over calloc (performance)?

On Thu, 14 Jun 2007, Matthew Dillon wrote: I'm going to throw a wrench in the works, because it all gets turned around the moment you find yourself in a SMP environment where several threads are running on different cpus at the same time, using the same shared VM space. The momen

Re: Reason for doing malloc / bzero over calloc (performance)?

I'm going to throw a wrench in the works, because it all gets turned around the moment you find yourself in a SMP environment where several threads are running on different cpus at the same time, using the same shared VM space. The moment you have a situation like that where y

Re: Reason for doing malloc / bzero over calloc (performance)?

[EMAIL PROTECTED] wrote: > Do you know if that's with malloc or calloc? What portion of the source > demonstrates this? No source, but here's a quote from http://boredzo.org/blog/archives/2006-11-26/calloc-vs-malloc: For large blocks (where "large" is surprisingly small, something like 14 KB) Ma

Re: Reason for doing malloc / bzero over calloc (performance)?

On Thu, 14 Jun 2007, Ivan Voras wrote: [EMAIL PROTECTED] wrote: Hmmm... I wonder what the Mach kernel in OSX does to allocate memory then. I'll have to take a look at OpenDarwin's source sometime and see what it does. Following the link chain from the benchmark link posted in this thread I'v

Re: Reason for doing malloc / bzero over calloc (performance)?

[EMAIL PROTECTED] wrote: > Hmmm... I wonder what the Mach kernel in OSX does to allocate memory > then. I'll have to take a look at OpenDarwin's source sometime and see > what it does. Following the link chain from the benchmark link posted in this thread I've come to the information that it's si

Re: Using shell commands versus C equivalents

Quoting [EMAIL PROTECTED] (from Wed, 13 Jun 2007 14:17:18 -0700 (PDT)): On Wed, 13 Jun 2007, Rick C. Petty wrote: Now another question is whether the pkg_* tools can handle multiple processes managing the ports at the same time. For the mostpart, this is true. Without looking at the code,

PAPI in the ports

Hello, I'm glad to announce you that PAPI-3.5.0 has reached the FreeBSD ports tree and now it's generally available for all FreeBSD users. Port information is available at http://www.freebsd.org/cgi/ports.cgi?query=papi&stype=all&sektion=devel See http://code.google.com/p/papi-for-freebsd/wi

Re: Using shell commands versus C equivalents

... > Sorry -- actually I meant that (along similar lines), there was a > program with the following lines: > > vsystem("/bin/chmod +x %s", filename); > > and I replaced it with: > > chmod(filename, (mode_t) ( S_IXUSR | S_IXGRP | S_IXOTH )); > > Probably won't yield much gain overall, but ever

Re: [PATCH]: acct_process() locking and exit1()

On Thu, Jun 14, 2007 at 09:54:39AM +0200, Roman Divacky wrote: > hi > > currently in exit1() we call acct_process() with Giant held. > I looked at the code and I think this is because of tty need > for Giant locking. Because of this we have to release process limit > in a separate PROC_LOCK()/UNL

[PATCH]: acct_process() locking and exit1()

hi currently in exit1() we call acct_process() with Giant held. I looked at the code and I think this is because of tty need for Giant locking. Because of this we have to release process limit in a separate PROC_LOCK()/UNLOCK() block. my just-to-look-at patch does this 1) moves the acct_process