
Unikernel Profiling from dom0 - yunong
http://www.brendangregg.com/blog/2016-01-27/unikernel-profiling-from-dom0.html
======
iheartmemcache
So, background info. B. Gregg was at Sun before the evil Oracle acquisition.
He quite literally wrote the book[0] on DTrace. Now he's at Netflix (i.e., he
has as far as I can tell no vested interest in either that Docker/Solaris
derivative [his interest is probably just getting great performance out
anything that works rather than some plebian Mirage/unikernel vs on-the-metal
BS we saw on Friday]). (Side-note, if you're reading this Mr. Gregg, your 2009
cheatsheet for DTrace[1] saved me countless hours on a production FreeBSD
machine circa 2011. I owe you big.)

I've read his work on-and-off for a long time and there's little no to
incendiary click-bait junk, or bias in most (if any) of what he publishes.
Obviously he can't dedicate 60-hour resources a post-doc might, but he
conducts most of his tests with rigor, and this blog post is no exception to
the high-standards to which he presumably holds himself. I'd love to see Anil
(one of the MirageOS leads (co-founder IIRC; pedigree - PhD from Imperial or
Oxbridge)) comment. Either way, this is an example of how one should construct
posts (I know we're not in academia, but there's no excuse for that absolutely
abysmal post[2] made on Friday).

Thanks for raising the caliber of conversation, my good man.

[0]
[http://www.amazon.com/gp/product/0132091518/ref=as_li_ss_tl?...](http://www.amazon.com/gp/product/0132091518/ref=as_li_ss_tl?ie=UTF8&tag=deirdrestraug-20&linkCode=as2&camp=217145&creative=399369&creativeASIN=0132091518)

[1] [https://blogs.oracle.com/brendan/resource/DTrace-
cheatsheet....](https://blogs.oracle.com/brendan/resource/DTrace-
cheatsheet.pdf)

[2] [https://www.joyent.com/blog/unikernels-are-unfit-for-
product...](https://www.joyent.com/blog/unikernels-are-unfit-for-production)

[https://news.ycombinator.com/item?id=10953766](https://news.ycombinator.com/item?id=10953766)
for the discussion

~~~
brendangregg
Thanks for the kind words, and I'm glad that cheatsheet was useful!

I'm sure if Anil or someone from the unikernel community is really interested
in this, we'll see a better profiler soon (of either type). The initial goal
should be to gather stacks for making into CPU flame graphs, which solve a ton
of issues.

------
dsp1234
Note that this is in stark contrast from the post last week titled "Unikernels
are unfit for production"[0]

One of that articles main ideas was:

 _"...the most profound reason that unikernels are unfit for production — and
the reason that (to me, anyway) strikes unikernels through the heart when it
comes to deploying anything real in production: Unikernels are entirely
undebuggable."_

[0] -
[https://news.ycombinator.com/item?id=10953766](https://news.ycombinator.com/item?id=10953766)

~~~
viraptor
Note that profiling and debugging are not the same. I agree that the other
author did not make much research effort, but for me: profiling = snapshots of
stack (r/o view), debugging = attaching interactive debugger (r/w view,
patching breakpoints).

~~~
teacup50
There's nothing stopping you from attaching a debugger to a VM -- this is
mighty handy for debugging boot loaders.

There's also nothing stopping you from including a runtime debugger interface
in your unikernel, just like any other kernel that supports debugging.

------
alexnewman
+1 for another great bredangregg article. [2]
[https://www.joyent.com/blog/unikernels-are-unfit-for-
product...](https://www.joyent.com/blog/unikernels-are-unfit-for-product..).

~~~
EvanPlaice
FYI, broken link.

