Linux 4.9 is out | Hacker News Reader

Linux 4.9 is out

lwn.net

208 pointssply44 comments

For anyone wondering, 4.9 is expected to be the next LTS kernel:

http://kroah.com/log/blog/2016/09/06/4-dot-9-equals-equals-n...

kernel 4.9 is the first kernel with full dynamic tracing support built in (beyond the power of systemtap, etc) . We are soon going to see tools like dtrace being built right for Linux.

Im excited for thw future of application development and monitoring on Linux. Imagine a whole bunch of tools more powerful than NewRelic.

Interesting, I assume you're referring to some extension of eBPF that happened in the 4.9 pulls. AFAIK eBPF already is pretty functional in 4.8. What got added that allows full dynamic tracing? (And what is full dynamic tracing?).

EDIT: Parent is probably referring to something mentioned here: http://www.brendangregg.com/blog/2016-10-27/dtrace-for-linux.... Apparently timed sampling got added, I quote Brendan:

> Timed sampling was the final major piece, and it landed in Linux 4.9-rc1 (patchset). Many thanks to Alexei Starovoitov (now working on BPF at Facebook), the lead developer behind these BPF enhancements.

This is indeed something possible with DTrace that was difficult (or not very efficient) to do with eBPF before. I assume one could've hooked into one of the kernel interrupt/... functions and used that as a ghetto timer, but the gymastics to convert that to real time might've been daunting.

The amount of times the word "updates" appears in the commits makes me feel much better at my difficulty of choosing succinct and unique commit messages.

Those are summaries of summaries of branches of commits. Actual commit and merge messages all have good titles and descriptions.

full list: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... (very "slow" at the very end of the development cycle)

example merge: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

example commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

I picked some of the longer ones on the first page just for contrast with your impression, many have shorter commit messages, but they all have a commit message with some explanation.

Note that those aren't "change commits", but merge commits aggregating large swathes of other changes. And it's not even all merge commits, it's just the merges from Linus' "top lieutenants".

But I sympathize. I often spend more time on commit messages than the actual changes...

Writing long commit messages (especially for internal/private projects) often gives me a slightly forlorn feeling, knowing that these words will almost certainly never be read again by another person, and possibly even I might never see them again. I persist only because when they do get read, they can be absolutely invaluable in explaining what on earth I was thinking at the time.

I persist only because when they do get read, they can be absolutely invaluable in explaining what on earth I was thinking at the time.

I wish I could upvote this more than once.

I really am thankful that you do write long commit messages. As a student starting out in OSS, I have had to track down why the particular piece of code is written like it and I go hunting down git blame and that really helps me. I also follow the practice when I can and hope that it helps future contributors or maintainers.

Indeed - when you go and look at the individual commits, the commit messages tend to be a lot more complex :)

My worst commit-message-to-code-changed ratio is a commit in the kernel with a 1307 char/175 word commit message, and a single character change...

Arguably you could frame that as "best".

Link for the curious?

It was a fix in PCI error handling on powerpc for a reasonably rare situation where the PCI card doesn't successfully come back up after we reset the slot or the PCI controller...

https://github.com/torvalds/linux/commit/949e9b827eb4736d96d...

I remember reading about bufferbloat related patches in 4.9 that would make network quite a lot more efficient. Curious to see in practice.

BBR congestion control is amazing. You can read about it here: http://queue.acm.org/detail.cfm?id=3022184

The team made a talk recently, I'll url it when I get back.

Yes, the BBR developments seem to help TCP connections a lot.

There is also a lot of good research going on in the "Make Wi-Fi Fast" project. See https://www.bufferbloat.net/projects/make-wifi-fast/wiki/

For concrete results, see June 2016 paper: "Fixing the WiFi Performance Anomaly" at https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-a...

Read the archives of the "Make-wifi-fast" mailing list at: https://lists.bufferbloat.net/listinfo/make-wifi-fast

If you want to use bleeding edge LEDE code (spinoff of OpenWrt) to see if your Wi-Fi is faster than mine, try: https://kau.toke.dk/lede/airtime-fairness-builds/ar71xx/gene...

Get your lag down to milliseconds no matter how you load your network.

Intel memory protection key support is nice. QEMU now also has support for emulation of pkeys, but naturally you can't use them with KVM/hw acceleration (because you don't have hardware to support them). This is generally enough for testing/designing, though. (The performance of memory protection keys will be important however, so it's not helpful to really determine that yet.)

That said, I'd suggest obviously building your own minimal kernel/chroot to do these tests, since the lack of KVM/available hardware makes emulation turn-around time fairly terrible for right now.

Still no sign of NVMe "RAID" support: http://marc.info/?t=147709622400002&r=1&w=2

There's already a patch (due for 4.10) to detect and warn about this silliness. Since the Intel guy says that all the systems that shipped with this mode now have firmware updates to allow disabling it, there's very little reason for anyone to implement full support.

Hopefully in the future Intel will think twice before implementing ugly firmware-level hacks to aid in working around limitations of Microsoft's driver stack.

What real world impact does changing from (fake) RAID to AHCI have?

That's the firmware setting that disables the hack that hides NVMe devices behind the chipset's AHCI controller. Aside from making it possible for standards-compliant NVMe drivers to function as expected, not lying to the OS about the hardware topology also allows the OS to access the PCI configuration space (allowing for eg. ASPM support) and not unnecessarily share interrupts between two entirely separate devices.

So it'd be better for Linux to support this RAID/NVMe mode natively, right?

If it served a useful purpose in the first place, yes. And if it were properly documented and didn't cripple certain areas of functionality (and probably hurt performance a bit, but I don't yet have a system to measure this with).

The Kernel Newbies LinuxChanges page hasn't been updated yet, but when it is, it'll be at https://kernelnewbies.org/LinuxChanges.

Should I be worried about Kernel Newbies? The forum is overrun by spam and it looks like the wiki wasn't updated for 4.8.

I've never read the forum but the kernel summaries are fantastic.

There's a changelog for 4.8 under this URL: https://kernelnewbies.org/Linux_4.8

Not sure why it wasn't copied to the wiki, maybe because of

> Warning: /!\ /!\ The changelog is not complete. It will be available during the next week.

Heh, I hadn't noticed that it was still a 4.7 summary. :(

I wonder what "DRM updates" and "DRM fixes" include.

DRM there refers to Direct Rendering Manager[0].

A few days ago the author those changes are listed under (Dave Airlie) was on the HN frontpage for his comments on an AMD RFC[1].

[0] https://en.wikipedia.org/wiki/Direct_Rendering_Manager

[1] https://news.ycombinator.com/item?id=13136426

so when the AMD patch was refused, it was refused for this LTS version of the kernel? that's gotta be a huge blow against AMD, no?

The merge window for 4.9 closed long before this recent spate of publicity. The AMDGPU patch would have been on track for more like 4.11.

ah ok, thanks for the information.

DRM in the context of the Linux kernel refers to the Direct Rendering Manager, a graphics component. If you want to see all the merge commits from Dave Airlie (the long descriptions of which include a list of commits), try https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

Updates to the Direct Rendering Manager, nothing sinister.

https://en.wikipedia.org/wiki/Direct_Rendering_Manager

I think they probably mean "direct rendering manager", rather than "digital rights management." It's used for graphics acceleration.

In the Linux kernel context, DRM is "Direct Rendering Manager"

It's not about Digital Rights Management. It's Direct Rendering Manager.

It's these merge commits:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...

Now the corresponding Linux Kernel Newbies page takes ages to be updated and reflect the changes ;-(

"make localmodconfig" in case you're compiling the kernel

Why are Linux changelogs so unbelievably shitty? I read it and I have no idea what changed. But, hey, at least I know who fucking changed it, right?

The problem, as I understand it, is that these are summaries of summaries. The actual commit messages are incredibly detailed, then they get rolled up by the lieutenants into a single merge with one line per change, then Linus merges them in and adds to the final summary 'networking updates'. If you want to know what actually changed, then look at the commit logs, e.g.:

https://github.com/torvalds/linux/compare/v4.9-rc8...v4.9

Linus provided a TL;DR: A bit over two thirds drivers (staging, GPU and networking are the bulk of it, but it's all over), with the rest looking fairly normal too: arch updates, documentation, generic networking, filesystems..

Reply on news.ycombinator.com