Re: more graphs
Bill Yerazunis <[email protected]>
| Newsgroups | gmane.mail.spam.crm114 |
|---|---|
| Message-ID | <[email protected]> |
From: "Ger Hobbelt" <[email protected]> Eric, Bill, >> Please tell me that you're not spinwaiting? Please? > > I'm not spin waiting. Don't know what the hell the file system lock is doing > however. Just an odd thought right here, but since Eric is running inside a Virtual Machine, operating system support for mmap() is executed _within_ that VM. I do not know how well those VMs support this kind of operation these days, but I can imagine the hardware/CPU support is 'faked' to allow the VM to keep control over what is happening inside it: that means there might be another layer of page mapping or some such in there, introduced by the VM to make it work. Eric has mentioned before that when running his goods right on top of the iron itself - no VM involved - the load factors are very nice. I hope that is still the case today. The thought is this (since Eric is using VMware, right?) that it _might_ be handy to _also_ ask the VMware boys about possible issues with mmap() performance inside their VMs and how to alleviate those, if possible. If they cannot shed any light on it, we're in for a serious bit of profiling; the crm built-in profiler is per script statement, so I guess that one is too coarse to get us any extra info on this. Will need a more fine grained profiler for this: anyone know a by-C-source-code-line profiler for UNIX? Yes. gmon will do that. In fact, it's "latent" in the Mainline Makefile; just flip the CFLAGS to the full debug mode and you'll get the gmon output for free. :) - Bill Yerazunis ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/