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

Dtrace for Linux

gnu.wildebeest.org

Post reply on HN
Print view View original

51–60 of 108 posts

Re: Dtrace for Linux

#51

Post by nailer »

brendangregg wrote: post #25
nailer wrote: post #23

Earlier quoted context omitted.

IIRC one of the big things about dtrace vs systemtap is that dtrace could trace a process from userspace to kernel space and then back again. Can eBPF do this? How else do they compare?

That would not be recalling correctly: SystemTap does that, and so does eBPF (via uprobes and kprobes). A large problem with SystemTap is that it was developed in the open, and in the early days people were scared off with its kernel panics. SystemTap built a negative brand: first impressions matter. DTrace, however, was largely built before its public release, and with the help from many other engineers and test tea…

Thanks. How does the stap language being compiled into kernel modules differ from an interpreter? Both seem to have a limited surface (unless you're doing C directly in systemtap)

Re: Dtrace for Linux

#52

Post by kyaghmour »

brendangregg wrote: post #9

Unfortunately for DTrace, this is too late. Oracle should have done this years ago. Now Linux has a more powerful tracer builtin, eBPF, and it would be a backwards step to switch the kernel code to DTrace (assuming the DTrace port is completed, which it is not). I'm sure this will not be lost on the maintainers, who have the ultimate say as to what is included in Linux mainline. The only hope for DTrace is to have th…

Indeed. There's probably some sort of Greek tragedy to be written about the story of tracing and Linux. Or maybe we can just go for a beer at the next LPC and laugh this one out ;)

Re: Dtrace for Linux

#53

Post by slrz »

gmueckl wrote: post #43
nordsieck wrote: post #39

Earlier quoted context omitted.

> There's a reason that copyright assignment agreements are rare. In a lot of jurisdictions, it's not even possible. How is a software development business possible under those circumstances? In the US one of the core pieces of every employment contract (for software developers) is IP assignment.

I can only speak for Germany. Here, we have a big exception to the normal rule that you own the rights and cannot reassign them: everything you create during work hours under a normal employment contract is automatically the property of your employer. Even if you create stuff outisde work that may be useful for the employer, the company has access and may get the rights (for a fair compensation according to the law).…

Matches my knowledge, except for the following part:

> Even if you create stuff outisde work that may be useful for the employer, the company has access and may get the rights (for a fair compensation according to the law).

Where does this come from?

Re: Dtrace for Linux

#54

Post by michaelmrose »

rollcat wrote: post #26
HankB99 wrote: post #20

Earlier quoted context omitted.

> ... but it would still be annoying to actually use ZFS in Linux for the same reason it is annoying to use it now. For those of us who are ignorant of what is annoying to use now (I raise my hand) can you elaborate? I'm fooling around with it on Debian Stretch and Ubuntu 16.04 LTS and haven't yet found it annoying (except for the challenge of finding where the various command line switches are documented...) I was p…

Running ZFS (boot&root) on both Ubuntu 17.10 on my home server and Debian Jessie on my laptop. The ZFS experience between the two is heaven and hell. Ubuntu just ships the zfs.ko and basically everything works 100% of the time, zero effort. Debian OTOH has to compile the module via DKMS for every minor kernel release... You better track those apt upgrades carefully, and run `dkms status` after each one, or you might…

The biggest issue is actually the fact that both require a gui installer that doesn't support zfs.

Regarding rebuilding zfs isn't that done automatically when you upgrade your kernel?

On funtoo I simply don't upgrade my kernel automatically EVER and when I do its part of a script that rebuilds everything required. Little chance of misfire.

ZFS as root is actually valuable it means you can roll the entire system back at need I have no idea why you would want to give that up.

Re: Dtrace for Linux

#55

Post by severino »

jsiepkes wrote: post #4

Really cool! However isn't it a bit too late for DTrace to gain market share on Linux now SystemTap and all have gotten such a head start? For me personally I like the idea of being able to use my DTrace skills (which I gained on FreeBSD and SmartOS) on Linux!

Well, it's never too late!

I mean, when reading articles like this one:

http://www.brendangregg.com/blog/2015-07-08/choosing-a-linux...

Linux tracing looks like a mess, where there're dozens of incompatible alternatives, each one with its gotchas. But instead, dtrace is a mature standard framework which also works under BSD or macOS. You got one programming language, D, and tons of resources out there.

So... my best wishes for this.

Re: Dtrace for Linux

#56

Post by adrianratnapala »

bri3d wrote: post #50
aardvark291 wrote: post #46

Earlier quoted context omitted.

What does this mean? I don't really understand the quote.

BPF started as the Berkeley Packet Filter, a language for declaring network packet filtering rules and eventually, a pretty good JITted virtual machine runtime for applying these rules quickly. However, it's since evolved to a generic filtering VM and been applied to system trace and other kernel-level filtering usecases. Historically, threads on Linux were implemented as process-alike tasks and even had unique PIDs,…

So then it is not correct to say a semantic patch is a lint rule. Rather semantic patches are both tools that attack the same problem from different angles. Arguably semantic patches are far superior if they can really be made to work.

Re: Dtrace for Linux

#57

Post by _ph_ »

gribbly wrote: post #44
Annatar wrote: post #40

Earlier quoted context omitted.

That day better never come; If the last thing I dearly love, illumos (there is no OpenSolaris any more) ever gets relicensed under that fascist GPL, I’ll never write another line of code again. That would be the last straw.

I can understand why someone does not like GPL, but calling a license which says you have to pass on the same rights you were given a 'fascist' license makes absolutely zero sense.

The issue with the GPL is, that it does not only requires to pass on the source any (modified) GPL component, but also any other program part which happens to be linked together with the GPL code, but is in no way derived from it. This is pretty violent towards code not strictly related to the GPL code - whether the strong term used is appropriate, is another question.

Re: Dtrace for Linux

#58

Post by twic »

bri3d wrote: post #50
aardvark291 wrote: post #46

Earlier quoted context omitted.

What does this mean? I don't really understand the quote.

BPF started as the Berkeley Packet Filter, a language for declaring network packet filtering rules and eventually, a pretty good JITted virtual machine runtime for applying these rules quickly. However, it's since evolved to a generic filtering VM and been applied to system trace and other kernel-level filtering usecases. Historically, threads on Linux were implemented as process-alike tasks and even had unique PIDs,…

Threads still have PIDs! I have had an issue on some heavily-loaded systems where a process dies but leaves a pidfile around, then its PID is reused for a thread in another process. When i run a restart script for the process, it reads the pidfile, confirms that the PID is alive, and then kills it - so shanking some random completely unrelated process.

I have modified the script to make some more careful checks before killing a PID it finds in a pidfile. Really, we should just use a proper process manager, but that probably won't happen soon.

Re: Dtrace for Linux

#59

Post by rhinoceraptor »

vetinari wrote: post #42
rhinoceraptor wrote: post #35

Earlier quoted context omitted.

I have a ZFS on root Arch setup, unfortunately Gnome 3 is such garbage nowadays that I hardly ever use it. It still doesn’t do display scaling correctly for 4K and it just crashes all the time.

There is something seriously wrong with your setup.

AFAICT, my issue isn't mine alone, Gnome 3 likes to crash when the display is disconnected. Some quick googling shows many other users with the same issue. I have my monitors hooked up to a wifi plug to turn them both off.

I'm running linux-lts and the proprietary nvidia LTS driver (on a GTX 1070), along with all the LTS versions of SPL, zfs, etc. Never had a problem with system stability, just Gnome.

And the display scaling issue, I have 2x28" 4k monitors which means I need fractional scaling. 1x is too small, 2x is too big. Windows can do it, macOS does it, but Gnome does not. I thought this was supposed to be fixed by Canonical for 18.04 but that seems less and less likely. There's supposed to be a way to fiddle with xrandr but with two monitors I've never been able to get it to work.

Re: Dtrace for Linux

#60

Post by caf »

blinkingled wrote: post #47
aardvark291 wrote: post #46

Earlier quoted context omitted.

What does this mean? I don't really understand the quote.

The Linux kernel treats threads no different than processes that share an address space which is unusual in UNIX land. Semantic patch probably refers to coccinelle - look it up, it's pretty cool, makes it easy to deal with API changes, renames etc. eBPF comes from extended Berkeley Packet Filter - where packet filter code is JITed to be fast. It's also used for dtrace like tracing along with kprobes to run profiling…

The Linux kernel treats threads no different than processes that share an address space which is unusual in UNIX land.

They also share a signal handler table, open file table and current working directory. If a process-directed signal is sent to the process any of the threads with the signal unblocked can handle it. If a default signal disposition causes one thread to exit (eg SIGKILL or SIGSEGV) then all threads in the process exit. The exit_group(2) syscall causes all threads to exit (which is used to implement the POSIX exit() libc function).

Really, "threads mostly are just processes" hasn't been true for a very long time. Mostly the only ways in which that is still true is in scheduling, where Linux schedules each thread independently (what POSIX calls PTHREAD_SCOPE_SYSTEM) and in credentials, where threads each have their own set of current, real and effective uids / gids (and glibc has to use a signal-based hack to synchronise them).

Post reply on HN