Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)

nullprogram.com

Post reply on HN
Print view View original

21–30 of 34 posts

Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)

#21

Post by __david__ »

greglindahl wrote: post #20
mjw1007 wrote: post #18

Earlier quoted context omitted.

The author evidently didn't find that option attractive: « 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. »

The usual trick to use strace in that kind of situation is to write a script named "curl" that runs curl under strace, and stick the script in your path. If the author is familiar with DTrace, though, sounds like that's a great solution for them.

I don't see why "strace -f" wouldn't suffice. I use that all the time for exactly these kinds of things.

Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)

#22

Post by bsder »

ink_13 wrote: post #5

> Linux has a reputation for Not Invented Here (NIH) syndrome, and these licensing issues certainly contribute to that 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.

The author also points out that "epoll" is a broken "kqueue".

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.

Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)

#23

Post by cryptonector »

ink_13 wrote: post #5

> Linux has a reputation for Not Invented Here (NIH) syndrome, and these licensing issues certainly contribute to that 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.

The SystemTap people did not even try to copy any part of DTrace. Now the eBPF stuff is... pretty much a copy of the best parts of DTrace. So, yeah, it was NIH.

Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)

#24

Post by dima55 »

mjw1007 wrote: post #18
drewg123 wrote: post #7

I'm a big fan of dtrace and I use it daily. However, the system call tracing that the author did here could easily have been done without dtrace. Eg, via strace on the curl process (or truss, ktrace, or whatever your OSe's system call tracer is).

The author evidently didn't find that option attractive: « 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. »

Linux now has a number of tools that can do this just fine. strace was the only tool LOONG ago. For the issue described in the article sysdig would be the tool I'd use, but that's just one option.

Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)

#25

Post by nlefler »

agumonkey wrote: post #11

Once again, a lovely article by Chris Wellons. Fun to see him having idols :) ps: the hammer story linked at the end is worth the minute reading http://archive.is/OV1kQ

Seems likely the origin of the parable is Charles Proteus Steinmetz:

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. """

Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)

#26

Post by m0zg »

While we're on the topic of tracing, does anyone know an _easy to use_ (!) tool that would roughly mirror the functionality of Apple Instruments for user-space tracking? I know there's lttng-ust and TraceCompass, but using either (and especially TraceCompas) is worse than pulling teeth. To display a simple trace in a "piano roll" / Gantt chart view with TraceCompass one has to read an encyclopedia sized tutorial and fumble their way through obscure XML (!) files to create their own visualizations. Let's just say, ease of use did not seem to be the goal at all.

Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)

#28

Post by yjftsjthsd-h »

Arnavion wrote: post #19
pmoriarty wrote: post #17

Earlier quoted context omitted.

"ZFS on Linux has now worked around the removal of the API." I'm just curious: how did they do that?

https://github.com/zfsonlinux/zfs/commit/0c593296e98e3ac95f1... + https://github.com/zfsonlinux/zfs/commit/26a856594f731db6244...

> Linux 5.0 compat: Disable vector instructions on 5.0+ kernels

Isn't that going to kill performance?

Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)

#29

Post by simcop2387 »

yjftsjthsd-h wrote: post #28
Arnavion wrote: post #19

Earlier quoted context omitted.

https://github.com/zfsonlinux/zfs/commit/0c593296e98e3ac95f1... + https://github.com/zfsonlinux/zfs/commit/26a856594f731db6244...

> Linux 5.0 compat: Disable vector instructions on 5.0+ kernels Isn't that going to kill performance?

Probably not going to be very noticeable, most of the cost in calculating the checksums is in IO, but it will mean that there's a lower ceiling on total possible 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.

Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)

#30

Post by pjmlp »

bsder wrote: post #22
ink_13 wrote: post #5

> Linux has a reputation for Not Invented Here (NIH) syndrome, and these licensing issues certainly contribute to that 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.

The author also points out that "epoll" is a broken "kqueue". 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.

Sadly the way it has grown, many take Linuxisms as how every UNIX does it.
Post reply on HN