I'd like to dig in here, but these results aren't hugely surprising for
this workload:  while I/O (be it disk or network) generally performs much
better under LX than KVM, some things perform more slowly.  In particular,
there is simply more work that we need to do on process exec (e.g., loading
lx_brand.so.1 and its dependencies like libc.so.1), so fork/exec/exit
benchmarks will likely always be faster on KVM than LX.  That said, we are
(of course) wanting LX to perform as well as it can for as many workloads
as it can -- and it would be great to gather some simple system call time
information here (e.g. "dtrace -n lx-syscall:::entry'{self->ts =
vtimestamp}' -n lx-syscall:::return'/self->tx/{@[probefunc] =
quantize(vtimestamp - self->ts)}'" running over the lifetime of the
build).  When we see things pop up there that are hot, we can move the
system calls into the kernel (saving a trip into the kernel and back out to
user-land on the system call) and/or look for other performance
optimizations.

Also, if you have early access on Triton and want to spin the workload up
there, I'd be happy to hop on and take a look...

        - Bryan


On Fri, Apr 3, 2015 at 12:32 PM, Ian Collins <[email protected]> wrote:

> One of my Linux work loads is building software so I use a clean build of
> gcc (C and C++ only) as a benchmark.  I've found this to be a reasonable
> benchmark given its mix of CPU and I/O bound phases.
>
> I was a little surprised to see an Ubuntu LX zone was slower building gcc
> 4.9 release than a KVM:
>
> LX Ubuntu:
>
> real    27m5.777s
> user    64m28.272s
> sys     15m7.446s
>
> KVM Ubuntu:
>
> real    21m54.977s
> user    61m8.702s
> sys    8m24.904s
>
> The host system is a quad core i7 and both machines had 8GB of RAM.
>
> Note the biggest difference is in the sys time.  Looking at the  LX zone
> with dtrace I see the syscalls I'd expect during as build (mainly
> open/mmap/stat/lstat/lseek/read) along with rt_sigaction and
> rt_sigprocmask in the top 5.
>
> Overall building on an LX zone was "kinder" to the host, the KVM process
> would max out the CPU and the load average during the build was much higher.
>
> --
> Ian.
>
>
>
> -------------------------------------------
> smartos-discuss
> Archives: https://www.listbox.com/member/archive/184463/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/184463/
> 21493597-819305a5
> Modify Your Subscription: https://www.listbox.com/
> member/?&
> Powered by Listbox: http://www.listbox.com
>



-------------------------------------------
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Reply via email to