[ale] Ouch

[Alex Carver via Ale]

https://it.slashdot.org/story/18/01/02/221254/kernel-memory-leaking-intel-processor-design-flaw-forces-linux-windows-redesign?utm_source=feedburnerFaceBook&utm_medium=feed&utm_campaign=Feed%3A+Slashdot%2Fslashdot+%28Slashdot%29&utm_content=FaceBook
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[James Sumners via Ale]

Well shit.

Post by Alex Carver via Ale
https://it.slashdot.org/story/18/01/02/221254/kernel-memory-
leaking-intel-processor-design-flaw-forces-linux-
windows-redesign?utm_source=feedburnerFaceBook&utm_medium=
feed&utm_campaign=Feed%3A+Slashdot%2Fslashdot+%28Slashdot%29&utm_content=
FaceBook
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Raj Wurttemberg via Ale]

Ohh.. yeah... Ouch!! A 30% performance hit?!?! I've never really had any
major issues with Intel processors but I built my new workstation with the
new AMD Ryzen 1700X (8 cores, 16 logical procs) processor and I really like
it. I run multiple VMs on it for work and I have never even seen it get
above 5%. The only thing I have done to make it warm for a few minutes is
transcoding video and burning DVDs. Even then, the GPU helps out and keeps
things moving smoothly.

/Raj

-----Original Message-----
From: Ale [mailto:ale-***@ale.org] On Behalf Of Alex Carver via Ale
Sent: Tuesday, January 2, 2018 9:53 PM
To: Atlanta Linux Enthusiasts <***@ale.org>
Subject: [ale] Ouch

https://it.slashdot.org/story/18/01/02/221254/kernel-memory-leaking-intel-pr
ocessor-design-flaw-forces-linux-windows-redesign?utm_source=feedburnerFaceB
ook&utm_medium=feed&utm_campaign=Feed%3A+Slashdot%2Fslashdot+%28Slashdot%29&
utm_content=FaceBook
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Solomon Peachy via Ale]

Post by Raj Wurttemberg via Ale
Ohh.. yeah... Ouch!! A 30% performance hit?!?!

It's actually not _that_ bad -- it's a significant performance hit on
making system calls -- the only measurements I've seen have shown a 38%
increase in the overhead to read() --actual processing is unaffected.

On the other hand, I/O intensive workloads are the most heavily
impacted. The PostgreSQL folks have done some preliminary benchmarks
and it's not pretty:

https://www.postgresql.org/message-id/***@alap3.anarazel.de

- Solomon

[Jim Kinney via Ale]

Good data. Thanks.

Post by Solomon Peachy via Ale

Post by Raj Wurttemberg via Ale
Ohh.. yeah... Ouch!! A 30% performance hit?!?!

It's actually not _that_ bad -- it's a significant performance hit on
making system calls -- the only measurements I've seen have shown a 38%
increase in the overhead to read() --actual processing is unaffected.
On the other hand, I/O intensive workloads are the most heavily
impacted. The PostgreSQL folks have done some preliminary
benchmarks
https://www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbk
- Solomon
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Alex Carver via Ale]

This also appears to extend to ARM64 as well:
https://lwn.net/Articles/740393/

That sucks more given how many ARM-based processors are around
(including phones) and can't exactly handle a 20-30% performance hit.

Post by Jim Kinney via Ale
Good data. Thanks.

Post by Solomon Peachy via Ale

Post by Raj Wurttemberg via Ale
Ohh.. yeah... Ouch!! A 30% performance hit?!?!

It's actually not _that_ bad -- it's a significant performance hit on
making system calls -- the only measurements I've seen have shown a 38%
increase in the overhead to read() --actual processing is unaffected.
On the other hand, I/O intensive workloads are the most heavily
impacted. The PostgreSQL folks have done some preliminary
benchmarks
https://www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbk
- Solomon

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Lightner, Jeffrey via Ale]

I just went through documentation at our Linux distro's site, our main server manufacturer's site and Intel's site. Am I reading all this correctly?

1) Are the OS patches only effective if we've also applied a CPU microcode/firmware update?

2) Intel's site seems to suggest it is relying on server manufacturers to push out microcode/firmware updates?

3) There seems to be discussion of a microcode_ctl at RedHat but some comments seem to suggest it isn't for everything (and/or may not exist any longer).

4) Assuming the foregoing and if the manufacturer isn't releasing a bios update for older servers does it mean there is no action I can or should take (other than replacing the hardware or insuring it is isolated)? i.e. Is there no point in applying the OS update if there is not a microcode/firmware update of the CPU as well?


-----Original Message-----
From: Ale [mailto:ale-***@ale.org] On Behalf Of Alex Carver via Ale
Sent: Wednesday, January 03, 2018 4:59 PM
To: Jim Kinney via Ale
Subject: Re: [ale] Ouch

This also appears to extend to ARM64 as well:
https://lwn.net/Articles/740393/

That sucks more given how many ARM-based processors are around (including phones) and can't exactly handle a 20-30% performance hit.

Post by Jim Kinney via Ale
Good data. Thanks.

Post by Solomon Peachy via Ale

Post by Raj Wurttemberg via Ale
Ohh.. yeah... Ouch!! A 30% performance hit?!?!

It's actually not _that_ bad -- it's a significant performance hit on
making system calls -- the only measurements I've seen have shown a
38% increase in the overhead to read() --actual processing is
unaffected.
On the other hand, I/O intensive workloads are the most heavily
impacted. The PostgreSQL folks have done some preliminary benchmarks
https://www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbk
- Solomon

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Leam Hall via Ale]

Post by Lightner, Jeffrey via Ale
3) There seems to be discussion of a microcode_ctl at RedHat but some comments seem to suggest it isn't for everything (and/or may not exist any longer).

There is a microcode_ctl patch in the current downloads. Already in
CentOS, too.

Leam
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Beddingfield, Allen via Ale]

I'm not sure about other distros, but SUSE and CentOS are distributing the microcode as a patch.

--
Allen Beddingfield
Systems Engineer
Office of Information Technology
The University of Alabama
Office 205-348-2251
***@ua.edu

On 1/8/18, 2:40 PM, "Ale on behalf of Lightner, Jeffrey via Ale" <ale-***@ale.org on behalf of ***@ale.org> wrote:

I just went through documentation at our Linux distro's site, our main server manufacturer's site and Intel's site. Am I reading all this correctly?

1) Are the OS patches only effective if we've also applied a CPU microcode/firmware update?

2) Intel's site seems to suggest it is relying on server manufacturers to push out microcode/firmware updates?

3) There seems to be discussion of a microcode_ctl at RedHat but some comments seem to suggest it isn't for everything (and/or may not exist any longer).

4) Assuming the foregoing and if the manufacturer isn't releasing a bios update for older servers does it mean there is no action I can or should take (other than replacing the hardware or insuring it is isolated)? i.e. Is there no point in applying the OS update if there is not a microcode/firmware update of the CPU as well?


-----Original Message-----
From: Ale [mailto:ale-***@ale.org] On Behalf Of Alex Carver via Ale
Sent: Wednesday, January 03, 2018 4:59 PM
To: Jim Kinney via Ale
Subject: Re: [ale] Ouch

This also appears to extend to ARM64 as well:
https://lwn.net/Articles/740393/

That sucks more given how many ARM-based processors are around (including phones) and can't exactly handle a 20-30% performance hit.

Post by Jim Kinney via Ale
Good data. Thanks.

Post by Solomon Peachy via Ale

Post by Raj Wurttemberg via Ale
Ohh.. yeah... Ouch!! A 30% performance hit?!?!

It's actually not _that_ bad -- it's a significant performance hit on
making system calls -- the only measurements I've seen have shown a
38% increase in the overhead to read() --actual processing is
unaffected.
On the other hand, I/O intensive workloads are the most heavily
impacted. The PostgreSQL folks have done some preliminary benchmarks
https://www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbk
- Solomon

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo


_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[DJ-Pfulio via Ale]

Read that Ubuntu is/will as well. "Additional Drivers"

The Ubuntu page about both issues is:
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown

They are testing 64-bit 4.x kernels for cloud images according to the
timeline.

They have been "driving" towards a 1/9 release for most of the updates.
Also, 16.04.x (whatever the next .x is) will be going to 4.13 kernels
early instead of fixing the 4.10.x kernels. I'm impacted by this for 1
system.

Post by Beddingfield, Allen via Ale
I'm not sure about other distros, but SUSE and CentOS are distributing the microcode as a patch.
--
Allen Beddingfield
Systems Engineer
Office of Information Technology
The University of Alabama
Office 205-348-2251
I just went through documentation at our Linux distro's site, our main server manufacturer's site and Intel's site. Am I reading all this correctly?
1) Are the OS patches only effective if we've also applied a CPU microcode/firmware update?
2) Intel's site seems to suggest it is relying on server manufacturers to push out microcode/firmware updates?
3) There seems to be discussion of a microcode_ctl at RedHat but some comments seem to suggest it isn't for everything (and/or may not exist any longer).
4) Assuming the foregoing and if the manufacturer isn't releasing a bios update for older servers does it mean there is no action I can or should take (other than replacing the hardware or insuring it is isolated)? i.e. Is there no point in applying the OS update if there is not a microcode/firmware update of the CPU as well?
-----Original Message-----
Sent: Wednesday, January 03, 2018 4:59 PM
To: Jim Kinney via Ale
Subject: Re: [ale] Ouch
https://lwn.net/Articles/740393/
That sucks more given how many ARM-based processors are around (including phones) and can't exactly handle a 20-30% performance hit.

Post by Jim Kinney via Ale
Good data. Thanks.

Post by Solomon Peachy via Ale

Post by Raj Wurttemberg via Ale
Ohh.. yeah... Ouch!! A 30% performance hit?!?!

It's actually not _that_ bad -- it's a significant performance hit on
making system calls -- the only measurements I've seen have shown a
38% increase in the overhead to read() --actual processing is
unaffected.
On the other hand, I/O intensive workloads are the most heavily
impacted. The PostgreSQL folks have done some preliminary benchmarks
https://www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbk
- Solomon

_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

--
Got Linux? Used on smartphones, tablets, desktop computers, media
centers, and servers by kids, Moms, Dads, grandparents and IT
professionals.
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Phil Turmel via Ale]

LWM covered the scramble in Linus' tree on Saturday....

https://lwn.net/Articles/742404/

Post by Alex Carver via Ale
https://it.slashdot.org/story/18/01/02/221254/kernel-memory-leaking-intel-processor-design-flaw-forces-linux-windows-redesign?utm_source=feedburnerFaceBook&utm_medium=feed&utm_campaign=Feed%3A+Slashdot%2Fslashdot+%28Slashdot%29&utm_content=FaceBook

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo