Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
nullprogram.com
nullprogram.com
Since then, bpftrace[0] has been released, supposedly it's actually better than dtrace, in the sense that it's even more capable[1].
See https://www.joyfulbikeshedding.com/blog/2019-01-31-full-syst... for a recent basic ebpf/bpftrace tutorial. Brendan Gregg also has a primer on eBPF: http://www.brendangregg.com/blog/2019-01-01/learn-ebpf-traci...
[0] http://www.brendangregg.com/blog/2018-10-08/dtrace-for-linux...
[1] that's Brendan Gregg saying it: http://www.brendangregg.com/blog/2018-10-08/dtrace-for-linux... — having contributed to it and being one of the leading dtrace experts
Examples? I don't see how it's more capable. Catching up with dtrace, maybe.
There's also no existing userland support. Everyone provides DTrace probes, no one systemtap probes.
The kernel verifier does extensive bounds checks on array uses and jumps in BPF programs.
Thanksfully there's now Oracle Linux with DTrace-proper.
When the usdt syntax can use static DTrace probes, why isn't it documented then? and why doesn't it use the familiar DTrace syntax then? Why is nobody using it?
You write this like you are implying that the DTrace designers somehow foresaw that spectre would be a thing and therefore array accesses would be a risk. This is obviously false. I’m sure there are reasonable reasons to not have arrays but predicting spectre 10 years before it was found is not one of them.
ps: the hammer story linked at the end is worth the minute reading http://archive.is/OV1kQ
https://www.smithsonianmag.com/history/charles-proteus-stein...
From the article:
""" Ford, whose electrical engineers couldn’t solve some problems they were having with a gigantic generator, called Steinmetz in to the plant. Upon arriving, Steinmetz rejected all assistance and asked only for a notebook, pencil and cot. According to Scott, Steinmetz listened to the generator and scribbled computations on the notepad for two straight days and nights. On the second night, he asked for a ladder, climbed up the generator and made a chalk mark on its side. Then he told Ford’s skeptical engineers to remove a plate at the mark and replace sixteen windings from the field coil. They did, and the generator performed to perfection.
Henry Ford was thrilled until he got an invoice from General Electric in the amount of $10,000. Ford acknowledged Steinmetz’s success but balked at the figure. He asked for an itemized bill.
Steinmetz, Scott wrote, responded personally to Ford’s request with the following:
Making chalk mark on generator $1.
Knowing where to make mark $9,999. """
« To run curl under strace from Emacs, I’d have to modify Emacs’ behavior to do so. With DTrace I can instrument every curl process without making a single change to Emacs, and with negligible impact to Emacs. That’s a big deal. »
If the author is familiar with DTrace, though, sounds like that's a great solution for them.
I don't think the author understands with NIH means in practise, and this completely misplaces the blame. It's not as though the kernel team was completely unwilling to consider porting ZFS or DTrace, it's that for legal reasons they were unable.
That's a huge difference to what NIH means, which is that just because I didn't make it, I'm not going to use it, I'll make my own version instead.
They couldn't ever use the original version of things because they're legally bound to not do so. The kernel has had a long standing policy of not keeping APIs that either they or userspace aren't using to reduce their burden and the case of keeping that API just for ZFS since literally nothing else in the kernel was using it wasn't a good enough argument to keep it. ZFS on Linux has now worked around the removal of the API.
I'm just curious: how did they do that?
Isn't that going to kill performance?
That also assumes though that the cost for handling the vector instructions in-kernel isn't higher than doing it without them. I believe that was part of the reason that the kernel started removing this from within drivers and other parts to begin with, the cost of saving all the floating point registers and other state is actually surprisingly expensive. So it may be a complete wash in the end anyway. If the kernel is no longer having to worry about saving those registers it can mean that the userspace doesn't pay that extra cost and now your compute ability is better for it without seriously affecting any of the rest of the system.
There are many other examples of this.
For example, because of the broken way Linux did file locking, NFS was terribly broken on Linux for a very long time.
Linux is popular, but that doesn't always make it correct.