13 ms·

Linux 4.9 is out

208 points by sply 10y ago

mparlane 10y ago
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.
- anarazel 10y ago
  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...
  - ajdlinux 10y ago
    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...
    - koolba 10y ago
      Arguably you could frame that as "best". Link for the curious?
      - ajdlinux 10y ago
        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/949e9b827eb4736d96df520c67d07a54c64e99b8 https://github.com/torvalds/linux/commit/949e9b827eb4736d96d...
  - wolfgang42 10y ago
    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.
    - grzm 10y ago
      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.
    - hashhar 10y ago
      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.
- deleted 10y ago
  [deleted]
- ploxiln 10y ago
  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.git/log/?id=refs/tags/v4.9 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.git/commit/?id=810ac7b7558d7830e72d8dbf34b851fce39e08b0 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... example commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=24d0492b7d5d321a9c5846c8c974eba9823ffaa0 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.
lucb1e 10y ago
I wonder what "DRM updates" and "DRM fixes" include.
- ddddddddq 10y ago
  In the Linux kernel context, DRM is "Direct Rendering Manager"
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- an_account_name 10y ago
  I think they probably mean "direct rendering manager", rather than "digital rights management." It's used for graphics acceleration.
- deleted 10y ago
  [deleted]
- Arcaire 10y ago
  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 https://en.wikipedia.org/wiki/Direct_Rendering_Manager [1] https://news.ycombinator.com/item?id=13136426 https://news.ycombinator.com/item?id=13136426
  - ramy_d 10y ago
    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?
    - wtallis 10y ago
      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.
deleted 10y ago
[deleted]
aseipp 10y ago
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.
gtirloni 10y ago
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-next-lts-kernel/ http://kroah.com/log/blog/2016/09/06/4-dot-9-equals-equals-n...
terrywang 10y ago
Now the corresponding Linux Kernel Newbies page takes ages to be updated and reflect the changes ;-(
voltagex_ 10y ago
Still no sign of NVMe "RAID" support: http://marc.info/?t=147709622400002&r=1&w=2 http://marc.info/?t=147709622400002&r=1&w=2
- wtallis 10y ago
  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.
  - voltagex_ 10y ago
    What real world impact does changing from (fake) RAID to AHCI have?
    - wtallis 10y ago
      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.
      - voltagex_ 10y ago
        So it'd be better for Linux to support this RAID/NVMe mode natively, right?
        wtallis 10y ago
        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).
ajdlinux 10y ago
The Kernel Newbies LinuxChanges page hasn't been updated yet, but when it is, it'll be at https://kernelnewbies.org/LinuxChanges https://kernelnewbies.org/LinuxChanges.
- voltagex_ 10y ago
  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.
  - koolba 10y ago
    I've never read the forum but the kernel summaries are fantastic.
  - ajdlinux 10y ago
    Heh, I hadn't noticed that it was still a 4.7 summary. :(
  - hansoku-make 10y ago
    There's a changelog for 4.8 under this URL: https://kernelnewbies.org/Linux_4.8 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.
sandGorgon 10y ago
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.
- aktau 10y ago
  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-2016.html 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.
known 10y ago
"make localmodconfig" in case you're compiling the kernel
agumonkey 10y ago
I remember reading about bufferbloat related patches in 4.9 that would make network quite a lot more efficient. Curious to see in practice.
- sanxiyn 10y ago
  BBR congestion control is amazing. You can read about it here: http://queue.acm.org/detail.cfm?id=3022184 http://queue.acm.org/detail.cfm?id=3022184
  - agumonkey 10y ago
    The team made a talk recently, I'll url it when I get back.
- richbhanover 10y ago
  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/ 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-anomaly-on-ath9k.html 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 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/generic/ https://kau.toke.dk/lede/airtime-fairness-builds/ar71xx/gene... Get your lag down to milliseconds no matter how you load your network.
  - bryce10 10y ago
    I would love to patch LEDE for BBR, but your link is not working and they probably won't update to kernel 4.9 any time soon.
zzzzz99997 10y ago
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?
- nattaylor 10y ago
  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..
- wolfgang42 10y ago
  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 https://github.com/torvalds/linux/compare/v4.9-rc8...v4.9

208 points by sply 10y ago

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.

anarazel 10y ago
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...
- ajdlinux 10y ago
  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...
  - koolba 10y ago
    Arguably you could frame that as "best". Link for the curious?
    - ajdlinux 10y ago
      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/949e9b827eb4736d96df520c67d07a54c64e99b8 https://github.com/torvalds/linux/commit/949e9b827eb4736d96d...
- wolfgang42 10y ago
  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.
  - grzm 10y ago
    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.
  - hashhar 10y ago
    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.
deleted 10y ago
[deleted]
ploxiln 10y ago
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.git/log/?id=refs/tags/v4.9 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.git/commit/?id=810ac7b7558d7830e72d8dbf34b851fce39e08b0 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... example commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=24d0492b7d5d321a9c5846c8c974eba9823ffaa0 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.

lucb1e 10y ago

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

ddddddddq 10y ago
In the Linux kernel context, DRM is "Direct Rendering Manager"
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
an_account_name 10y ago
I think they probably mean "direct rendering manager", rather than "digital rights management." It's used for graphics acceleration.
deleted 10y ago
[deleted]
Arcaire 10y ago
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 https://en.wikipedia.org/wiki/Direct_Rendering_Manager [1] https://news.ycombinator.com/item?id=13136426 https://news.ycombinator.com/item?id=13136426
- ramy_d 10y ago
  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?
  - wtallis 10y ago
    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.

deleted 10y ago

[deleted]

aseipp 10y ago

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.

gtirloni 10y ago

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-next-lts-kernel/ http://kroah.com/log/blog/2016/09/06/4-dot-9-equals-equals-n...

terrywang 10y ago

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

voltagex_ 10y ago

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

wtallis 10y ago
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.
- voltagex_ 10y ago
  What real world impact does changing from (fake) RAID to AHCI have?
  - wtallis 10y ago
    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.
    - voltagex_ 10y ago
      So it'd be better for Linux to support this RAID/NVMe mode natively, right?
      - wtallis 10y ago
        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).

ajdlinux 10y ago

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

voltagex_ 10y ago
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.
- koolba 10y ago
  I've never read the forum but the kernel summaries are fantastic.
- ajdlinux 10y ago
  Heh, I hadn't noticed that it was still a 4.7 summary. :(
- hansoku-make 10y ago
  There's a changelog for 4.8 under this URL: https://kernelnewbies.org/Linux_4.8 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.

sandGorgon 10y ago

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.

aktau 10y ago
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-2016.html 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.

known 10y ago

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

agumonkey 10y ago

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

sanxiyn 10y ago
BBR congestion control is amazing. You can read about it here: http://queue.acm.org/detail.cfm?id=3022184 http://queue.acm.org/detail.cfm?id=3022184
- agumonkey 10y ago
  The team made a talk recently, I'll url it when I get back.
richbhanover 10y ago
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/ 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-anomaly-on-ath9k.html 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 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/generic/ https://kau.toke.dk/lede/airtime-fairness-builds/ar71xx/gene... Get your lag down to milliseconds no matter how you load your network.
- bryce10 10y ago
  I would love to patch LEDE for BBR, but your link is not working and they probably won't update to kernel 4.9 any time soon.

zzzzz99997 10y ago

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?

nattaylor 10y ago
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..
wolfgang42 10y ago
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 https://github.com/torvalds/linux/compare/v4.9-rc8...v4.9