atom feed29 messages in org.freebsd.freebsd-emulationRe: [PATCH] pipe2 for Linuxulator
FromSent OnAttachments
Jung-uk KimApr 10, 2012 3:56 pm.diff
Jung-uk KimApr 10, 2012 4:39 pm 
Jung-uk KimApr 10, 2012 5:27 pm 
Alexander BestApr 13, 2012 1:31 pm 
Alexander LeidingerApr 14, 2012 6:50 am 
Alexander LeidingerApr 14, 2012 6:54 am 
Alexander BestApr 14, 2012 1:32 pm 
Alexander LeidingerApr 14, 2012 1:47 pm 
Alexander LeidingerApr 14, 2012 3:02 pm 
Alexander BestApr 14, 2012 5:01 pm 
Alexander BestApr 15, 2012 3:11 am 
Alexander BestApr 15, 2012 4:22 am 
Alexander LeidingerApr 15, 2012 4:44 am 
Alexander BestApr 15, 2012 4:50 am.Other
Alexander BestApr 15, 2012 6:02 am 
Alexander LeidingerApr 15, 2012 7:30 am 
Alexander BestApr 15, 2012 7:41 am 
Alexander BestApr 15, 2012 11:15 am 
Alexander BestApr 15, 2012 11:29 am 
Alexander BestApr 15, 2012 11:46 am 
Alexander LeidingerApr 15, 2012 11:52 am 
Alexander LeidingerApr 15, 2012 12:00 pm 
Alexander BestApr 15, 2012 12:03 pm 
Alexander LeidingerApr 15, 2012 12:05 pm 
Alexander LeidingerApr 15, 2012 12:16 pm 
Alexander BestApr 15, 2012 1:56 pm 
Alexander BestApr 15, 2012 2:03 pm 
Jung-uk KimApr 16, 2012 2:32 pm 
Alexander BestApr 21, 2012 3:16 pm 
Subject:Re: [PATCH] pipe2 for Linuxulator
From:Alexander Leidinger (Alex@Leidinger.net)
Date:Apr 15, 2012 12:00:40 pm
List:org.freebsd.freebsd-emulation

On Sun, 15 Apr 2012 18:29:28 +0000 Alexander Best <arun@freebsd.org> wrote:

On Sun Apr 15 12, Alexander Best wrote:

running stats_timing.d revealed something strange...according to this section:

Number of calls per provider/application/kernel function:

linuxulator32 npviewer.bin proc_exit 2

proc_exit only got callded twice. however according to this section:

Longest running (CPU-time!) functions per provider (in ns): linuxulator32 proc_exit -16995

the CPU spent a lot of time for those two calls.

AFAIR proc_exit walks down a list or two. Depending on how much is going on, this may take a while.

Looks like my DTrace probes and scripts offer the opportunity to do some performance related observations in an easy way. Now we just need some interested souls to actually do it and optimize some things. It would also be great if someone could have a look at http://dtrace.org/blogs/brendan/ and code up some nice GUI respectively an observation and analysis tool. Graphs as represented by Brendan give a much better way of understanding what's going on than a lot of numbers.

Bye, Alexander.