LWN: Comments on "Finishing out the 4.10 merge window"

Finishing out the 4.10 merge window

anton — Fri, 13 Jan 2017 18:19:27 +0000

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

spender — Sun, 08 Jan 2017 20:50:32 +0000

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

Finishing out the 4.10 merge window

spender — Sun, 08 Jan 2017 20:34:11 +0000

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

-Brad

Finishing out the 4.10 merge window

zlynx — Sat, 07 Jan 2017 19:55:00 +0000

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

davidstrauss — Sat, 07 Jan 2017 19:44:49 +0000

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

zlynx — Sat, 07 Jan 2017 19:41:51 +0000

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

pizza — Sat, 07 Jan 2017 16:11:38 +0000

> 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

pebolle — Sat, 07 Jan 2017 13:32:08 +0000

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

flussence — Sat, 07 Jan 2017 03:28:42 +0000

>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

davidstrauss — Fri, 06 Jan 2017 21:58:04 +0000

> 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?