Finishing out the 4.10 merge window [LWN.net]

By Jonathan Corbet
January 3, 2017

As expected, the 4.10 merge window ended on December 25 with the 4.10-rc1 release. In the end, 11,455 non-merge changesets were pulled into the mainline repository for 4.10, making this a reasonably busy development cycle, even if it falls far short of 4.9. Less than 400 of those changes were pulled after the December 22 summary was written, so the list of additional changes is short.

That list includes:

The PA-RISC architecture has gained support for kernel address-space layout randomization.
The cache-allocation technology patch set has been merged. These patches provide access to a new mechanism in Intel processors by which the processor's memory cache can be partitioned between processes. It can be used to keep one group of processes (a container, say) from dominating the cache, or to set aside a portion of the cache for a set of privileged processes.
There are new drivers for QLogic QEDI 25/40/100Gb iSCSI initiators and Loongson1 SoC hardware watchdogs.
The cycle_t type used for clock values inside the kernel has been removed; a plain u64 type is now used instead.

The 4.10 stabilization period got off to a slow start due to the holidays; only 27 non-merge changesets were applied between 4.10-rc1 and 4.10-rc2. The pace of change can be expected to pick up, though, as developers return to work and the final 4.10 release date (probably February 12 or 19) approaches.

Index entries for this article
Kernel	Releases/4.10

to post comments

Finishing out the 4.10 merge window

Posted Jan 6, 2017 21:58 UTC (Fri) by davidstrauss (guest, #85867) [Link] (9 responses)

> The PA-RISC architecture has gained support for kernel address-space layout randomization.

The last computer made with PA-RISC was in 2008. Any vendor support ended in 2013. Why would someone be working on this?

Finishing out the 4.10 merge window

Posted Jan 7, 2017 3:28 UTC (Sat) by flussence (guest, #85566) [Link] (5 responses)

>Why would someone be working on this?
That's actually a really good question; PA-RISC doesn't exactly sound like a thing someone hacks on for fun. I can imagine someone out there has a few racks full of the stuff and decided it's more cost-effective to just secure the kernel than replace the hardware.

Finishing out the 4.10 merge window

Posted Jan 7, 2017 16:11 UTC (Sat) by pizza (subscriber, #46) [Link] (4 responses)

> I can imagine someone out there has a few racks full of the stuff and decided it's more cost-effective to just secure the kernel than replace the hardware.

I have to imagine that today's commodity X86 hardware could run circles around the best PA-RISC gear made.. while using considerably less power in the process too.

Unless someone's truly stuck using PA-RISC due to legacy hardware -- or more likely, software requirements. That's where the real expense lies..

Finishing out the 4.10 merge window

Posted Jan 7, 2017 19:41 UTC (Sat) by zlynx (guest, #2285) [Link] (3 responses)

I'm not sure about modern stuff being that much faster.

I've got an older system that I use as a guest computer which is running an Intel 980x released in 2010. It is still very competitive in gaming (the video card is an AMD from 2014) and really not that much slower than the 5960x in my current gaming system.

Clock speeds are now very static and adding more execution units and better prediction helps but only on the right sort of work loads.

Finishing out the 4.10 merge window

Posted Jan 7, 2017 19:44 UTC (Sat) by davidstrauss (guest, #85867) [Link] (1 responses)

It's not only a matter of faster processors. There's power efficiency, storage, networking, memory, and other aspects that will also be limited in a 2008 chipset and build.

Finishing out the 4.10 merge window

Posted Jan 7, 2017 19:55 UTC (Sat) by zlynx (guest, #2285) [Link]

Yes true. Mostly about the power efficiency but that extra cost has to balance against replacing all of the hardware you've currently got.

Networking and storage in servers in my experience is mostly about the latency. It does depend on the application and perhaps you really do have a difference between 1 Gbps and 40 Gbps to the SAN, but for most things it is database indexing and record retrieval which takes the same number of milliseconds no matter how fast the link is.

And of course bigger faster RAM is nice and it is pretty great to get 256 GB on one node these days. But if you're using a multiple-terabyte sized database your cache hit rate isn't going to be *that* much better. Depends on the application.

So, I think it can be a reasonable decision to keep using old systems as long as they are performing well enough and the maintenance costs are lower than replacement costs.

Finishing out the 4.10 merge window

Posted Jan 13, 2017 18:19 UTC (Fri) by anton (subscriber, #25547) [Link]

The PA-RISC CPUs (like most other RISCs) have not kept up with Intel and AMD in the MHz race of the late 1990s and early 2000s (before the race hit the wall in 2003-2005), and the fastest one runs at 1100MHz, and has a 6400MB/s memory bus (compared to 19200MB/s for a single DDR4-2400 DIMM, with two accessible in parallel by a desktop Intel CPU), and the IPC (instructions per cycle) are likely also lower than on a current Intel CPU, so the PA-RISC is really much slower than a current Intel or AMD-based system.

But some of us like our old hardware. E.g., we have an Alpha running that we bought in 1998. These systems are not competetive as workhorses, but if you want to do experiments with the architecture or with software running on the architecture, they are the real thing; and if you don't have the real thing, you have nothing to validate a simulator against.

Finishing out the 4.10 merge window

Posted Jan 7, 2017 13:32 UTC (Sat) by pebolle (guest, #35204) [Link] (2 responses)

This snippet seems to be based on commit 18d98a79382c ("parisc: Enable KASLR").

Perhaps this Saturday is off to an even slower start than usual for me but that commit summary appears to be typoed as the commit itself apparently enables userspace ASLR for PA-RISC. Or did I misunderstand the commit?

Finishing out the 4.10 merge window

Posted Jan 8, 2017 20:34 UTC (Sun) by spender (guest, #23067) [Link] (1 responses)

You're not missing anything, you're correct.

-Brad

Finishing out the 4.10 merge window

Posted Jan 8, 2017 20:50 UTC (Sun) by spender (guest, #23067) [Link]

But now that I think about it, what better way to celebrate the 14 year anniversary of PaX adding ASLR support to PARISC than to do it in 2017 after the architecture is already dead, with the wrong acronym.

We can file that under the same achievement column as Andy/Linus/Ingo et al "reinventing" PaX's marking of the GDT as read-only and musing in public about whether it's possible to do while patting themselves on the back for their innovation -- PaX did it as early as 2003 (possibly even earlier, but my archives don't go back further than that). All this while "improving" KASLR yet again, while they all sheepishly ignore the numerous presentations from last year and earlier about how completely pointless it is, with attacks demonstrating exactly we had already told them back in 2011. It's PR-focused mental masturbation, not security, if the "defenses" they spend so much time on aren't even a road block for script kids who can run some off-the-shelf code.

-Brad