Finishing out the 4.10 merge window
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 |
Posted Jan 6, 2017 21:58 UTC (Fri)
by davidstrauss (guest, #85867)
[Link] (9 responses)
The last computer made with PA-RISC was in 2008. Any vendor support ended in 2013. Why would someone be working on this?
Posted Jan 7, 2017 3:28 UTC (Sat)
by flussence (guest, #85566)
[Link] (5 responses)
Posted Jan 7, 2017 16:11 UTC (Sat)
by pizza (subscriber, #46)
[Link] (4 responses)
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..
Posted Jan 7, 2017 19:41 UTC (Sat)
by zlynx (guest, #2285)
[Link] (3 responses)
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.
Posted Jan 7, 2017 19:44 UTC (Sat)
by davidstrauss (guest, #85867)
[Link] (1 responses)
Posted Jan 7, 2017 19:55 UTC (Sat)
by zlynx (guest, #2285)
[Link]
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.
Posted Jan 13, 2017 18:19 UTC (Fri)
by anton (subscriber, #25547)
[Link]
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.
Posted Jan 7, 2017 13:32 UTC (Sat)
by pebolle (subscriber, #35204)
[Link] (2 responses)
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?
Posted Jan 8, 2017 20:34 UTC (Sun)
by spender (guest, #23067)
[Link] (1 responses)
-Brad
Posted Jan 8, 2017 20:50 UTC (Sun)
by spender (guest, #23067)
[Link]
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
Finishing out the 4.10 merge window
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
Finishing out the 4.10 merge window
Finishing out the 4.10 merge window
Finishing out the 4.10 merge window
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.
Finishing out the 4.10 merge window
Finishing out the 4.10 merge window
Finishing out the 4.10 merge window
Finishing out the 4.10 merge window