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/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.