Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Linux

What's New in Linux 5.2? (crn.com.au) 68

diegocg writes: Linux 5.2 has been released. This release includes Sound Open Firmware, a project that brings open source firmware to DSP audio devices; open firmware for many Intel products is also included. This release also improves the Pressure Stall Information resource monitoring to make it usable by Android; the mount API has been redesigned with new syscalls; the BFQ I/O scheduler has gained some performance improvements; a new CLONE_PIDFD flag lets clone(2) return pidfs usable by pidfd_send_signal(2); Ext4 has gained support for case-insensitive name lookups; there is also a new device mapper target that simulates a device that has failing sectors and/or read failures; open source drivers for the ARM Mali t4xx and newer 6xx/7xx have been added. Many other new drivers, features and changes can be found in the changelog.
But there's more besides supporting "a handful of extra ARM-powered single-board computers," according to CRN: The biggest feature in 5.2 is probably support for Intel's forthcoming Comet Lake architecture, which will power the tenth generation of its Core desktop and mobile CPUs due. The new silicon is due to ship late in 2019 and appear in products early the next year.

Linux 5.2 also includes many tweaks that improve its performance on laptops.

This discussion has been archived. No new comments can be posted.

What's New in Linux 5.2?

Comments Filter:
  • by UnknowingFool ( 672806 ) on Saturday July 13, 2019 @12:13PM (#58919792)
    One of the things people have found in testing the new Ryzen 3 chips is that cores on the same chiplet work much better together than cores in different chiplets even with improvements to the Infinity Fabric. This is not suprising but does this version of Linux optimize for that and will it ever optimize for that?
    • by link-error ( 143838 ) on Saturday July 13, 2019 @12:40PM (#58919912)

      I read those enhancements are close to ready, but didn't make it into the 5.2 release. I can't find where I read that, but here is the related info for the Zen 2 processors on Linux.
      https://www.phoronix.com/scan.... [phoronix.com]

    • by gweihir ( 88907 )

      Give it a bit of time. Most developers will just have gotten access to Ryzen 3 machines or may still not have it.

    • by KiloByte ( 825081 ) on Saturday July 13, 2019 @04:08PM (#58920894)

      One of the things people have found in testing the new Ryzen 3 chips is that cores on the same chiplet work much better together than cores in different chiplets

      Or in other words, it's a regular multi-processor NUMA machine despite being physically single-socket and marketed as such. People have worked with multi-socket boxes for a long time, and problems, solutions, and limitations to those solutions are well known. AMD just tried to shove this under the carpet.

      For example, 2990WX has 4 NUMA nodes, nodes 0 and 2 get assigned RAM, nodes 1 and 3 have nothing but 16MB of L3 cache (plus L1 and L2). It works the same as any multi-socket machine I've seen: cacheline ping-pong being slow, other-node access being slow, synchronization being slow, etc. And just the same you want to restrict tasks and their memory to reside entirely on one of those nodes.

      It's just that 1. AMD didn't warn about the problem, and 2. it's a consumer CPU thus users nor user-facing developers are not educated how to deal with this (as opposed to data center people). So eg. this bit:

      43:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev e1) (prog-if 00 [VGA controller])
              Subsystem: Sapphire Technology Limited Nitro+ Radeon RX 570/580
              NUMA node: 2
      means I should run graphical games on node 2 only. Some other early adopters also reported such framerate drops unless numactl'ed; on the other hand I'm not a gamer so despite owning this machine for 3 months I still didn't get around to check out a modern game.

      • by UnknowingFool ( 672806 ) on Sunday July 14, 2019 @11:51AM (#58924530)

        Or in other words, it's a regular multi-processor NUMA machine despite being physically single-socket and marketed as such. People have worked with multi-socket boxes for a long time, and problems, solutions, and limitations to those solutions are well known. AMD just tried to shove this under the carpet

        Except that it's not "a regular multi-processor NUMA machine". It's a design in between multi-core single chip and multi-chips.

        It's just that 1. AMD didn't warn about the problem, and 2. it's a consumer CPU thus users nor user-facing developers are not educated how to deal with this (as opposed to data center people). So eg. this bit:

        What do you mean "warn"? AMD has been very open about what it was doing with chiplets and has been talking about Infinity Fabric since Ryzen 1 [wccftech.com] and how Infinity Fabric was going to be used to connect the chiplets.

        means I should run graphical games on node 2 only. Some other early adopters also reported such framerate drops unless numactl'ed; on the other hand I'm not a gamer so despite owning this machine for 3 months I still didn't get around to check out a modern game.

        My question is not about the optimizations between GPU and CPU for gaming in Windows. My question was specifically core optimization in Ryzen 3 in the same chiplet vs across chiplets in Linux.

        • by KiloByte ( 825081 ) on Sunday July 14, 2019 @05:06PM (#58925814)

          Except that it's not "a regular multi-processor NUMA machine". It's a design in between multi-core single chip and multi-chips.

          It drastically loses speed when you have accesses cross-chiplet, just same as happens with multiple sockets. I'm a purely software programmer, thus I don't know details of the design, only effects that are observable for me. And for those, this CPU behaves similar as multi-socket machines.

          My question is not about the optimizations between GPU and CPU for gaming in Windows.

          I wouldn't put Windows in the same building as a 64-thread machine.

          My question was specifically core optimization in Ryzen 3 in the same chiplet vs across chiplets in Linux.

          "Ryzen 3" means only market segment, just like i3/i5/i7/i9. There are Ryzen 3 CPUs for both Zen and Zen+, and certainly there'll be some for Zen 2. Are you perhaps talking about Zen 2? Ie, the first digit of the 4-digit symbol being 3 (looks like AMD follows Intel when going for maximum confusion in product names...). If so, I can't help you -- I have only a single big Zen+ box, which fares badly for your question.

  • Sound Open Firmware, a project that brings open source firmware to DSP audio devices

    Hey, will this support my IBM Mwave card?

  • by gweihir ( 88907 ) on Saturday July 13, 2019 @12:53PM (#58919986)

    The stupid brigade must have gotten in. That is about the absolutely worst way to do it. Of course, that is what Microsoft chose, but must the Linux kernel now also get abysmal engineering choices? Of course, this sickness has gotten into Linux userspace a while ago with systemd and other atrocities. I had hoped the kernel was immune, but sadly it does not seem to be.

    • by Anonymous Coward

      Of course, that is what Microsoft chose, but must the Linux kernel now also get abysmal engineering choices?
      OS X is also case-insensitive. (You can enable support for case-sensitivity by reformatting but then things may break.)

    • by Aighearach ( 97333 ) on Saturday July 13, 2019 @02:21PM (#58920400)

      Unfortunately, you saw the stupid brigade passing by and joined it.

      They're not getting rid of case sensitivity, they're adding support for case-insensitive lookups.

      Like with systemd, the technical details do matter.

      • by gweihir ( 88907 )

        I am aware of the technical details and that this is "just" an option. If anything, having two different modes is _worse_.

    • by Anonymous Coward on Saturday July 13, 2019 @03:06PM (#58920630)

      but must the Linux kernel now also get abysmal engineering choices?

      If you follow lwn.net, you'd know it was a (somewhat reasonable) engineering choice. Supporting Samba efficiently requires some level of case insensitivity and that works best in the kernel where file changes can be tracked as well as dealing with filename conflicts. I do agree that it's pretty abysmal to more or less require the support, but that's a consequence of trying to be compatible with other systems. It's not reasonable to drop the support or ignore that there's a pretty substantial performance penalty to avoid this being in the kernel.

      Having said all that, I'd still prefer that this was handled in a better way by punting more of this into a user process with kernel hooks, but that'd require a lot more work to actually fix inotify/fanotify to be more than just best effort and otherwise fix their shortcomings. Of course, that would be better overall for the kernel anyways. The real issue, of course, is that now the support is in the official kernel it likely will never be removed even if the needed work is introduced to avoid what will likely just be a huge mess.

      I had hoped the kernel was immune, but sadly it does not seem to be.

      There's been plenty of kernel design fuck ups. Thankfully Linus and the kernel developers have been willing to admit it, mostly, when new stuff comes along--proper attribution and NIH rewrites not withstanding. That's probably the best part about the Linux kernel--a willingness to grow even if it's incredibly painful. There's still a lot of outstanding problems with Linux--the OOM killer is a big one*, IMO. Even so, it's constantly making progress. So, I'm still hopeful. Now if only they could work around the SB Live DMA32 bug...

      * I've had the OOM killer triggered on a 16GB and 32GB system where 3/4ths of RAM was being used for cache and a 4GB swap was empty. It eventually pushed me to switch to vm.overcommit_memory=2 which has, knock on wood, so far not had a kernel panic or any other issues. I've no idea if the core cause was cache and slow HDD writes, some specific combination of mallocs in rapid succession, temporarily high memory fragmentation, or something else. What is clear is the OOM killer is nearly useless at spelling out the actual circumstances on why it runs and is too stupid to know to not kill anything when it's inappropriately invoked. This all, indirectly, stems from overcommit just being a bad idea.

    • "support for case-insensitive name lookups" != "case insensitive filenames"

      • Re: (Score:2, Interesting)

        by gweihir ( 88907 )

        I am aware of that. It does not change the level of stupidity in this decision.

        • The only thing here unchanged is your usual onesided view of everything supported by the mountain of ignorance from which you are looking. Maybe go read some mailing lists before you declare something stupid lest you look stupid yourself.

          • by gweihir ( 88907 )

            Well, same back at you. What makes you think I have not looked at things? Only your own arrogance and assumption of superiority.

  • by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Saturday July 13, 2019 @03:56PM (#58920848) Homepage Journal

    A comet lake is what you wind up with after a comet crashes into the ground, leaving a smoking hole.

    Fingers crossed

  • by Anonymous Coward

    https://www.freebsd.org/releases/11.3R/announce.html
    https://www.freebsd.org/releases/12.0R/announce.html

    I was a professional Linux user and admin for over a decade, after entering a new environment and having tried FreeBSD at home and now in fulltime production work, I have no desire to go back to Linux at all.

    FreeBSD is incredibly simple and easy to run, it is very lightweight with no layers upon layers of admin and user abstraction, very stable, and updates and things are so well structured that I've free

Keep up the good work! But please don't ask me to help.

Working...