[ale] Ouch

[Beddingfield, Allen]

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
allen at ua.edu

On 1/8/18, 2:40 PM, "Ale on behalf of Lightner, Jeffrey via Ale" <ale-bounces at ale.org on behalf of ale at 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-bounces at 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.
    
    
    
    On 2018-01-03 07:04, Jim Kinney via Ale wrote:
    > Good data. Thanks. 
    > 
    > On Wed, 2018-01-03 at 07:47 -0500, Solomon Peachy via Ale wrote:
    >> On Tue, Jan 02, 2018 at 10:24:07PM -0500, Raj Wurttemberg via Ale
    >> wrote:
    >>> 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/20180102222354.qikjmf7dvnjgbk
    >> xe at alap3.anarazel.de
    >>
    >>  - Solomon
    _______________________________________________
    Ale mailing list
    Ale at 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 at ale.org
    http://mail.ale.org/mailman/listinfo/ale
    See JOBS, ANNOUNCE and SCHOOLS lists at
    http://mail.ale.org/mailman/listinfo