Re: [ADSM-L] Spectre & Meltdown patching in relation to Spectrum Protect

 Content preview:  Hi Stefan, My understanding is that Meltdown and Spectre took
    advantage of having the kernel in the same address space as each user-space
    process. Previously this was done to reduce the number of cache and TLB 
misses
    around system calls, but at least for Linux, the mitigation involves 
removing
    the kernel from each process's address space. This means that every system
    call potentially involves cache/TLB invalidation, so applications that are
    heavy on system calls like TSM are likely to see more of a performance 
impact
    than entirely CPU-bound applications. [...]

 Content analysis details:   (0.6 points, 5.0 required)

  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  0.7 SPF_NEUTRAL            SPF: sender does not match SPF record (neutral)
 -0.0 T_RP_MATCHES_RCVD      Envelope sender domain matches handover relay
                             domain
X-Barracuda-Connect: mx.gs.washington.edu[128.208.8.134]
X-Barracuda-Start-Time: 1516717828
X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384
X-Barracuda-URL: https://148.100.49.27:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at marist.edu
X-Barracuda-Scan-Msg-Size: 2094
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=3.5 
QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.5 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.47174
        Rule breakdown below
         pts rule name              description
        ---- ---------------------- 
--------------------------------------------------

Hi Stefan,

My understanding is that Meltdown and Spectre took advantage of having the
kernel in the same address space as each user-space process. Previously
this was done to reduce the number of cache and TLB misses around system
calls, but at least for Linux, the mitigation involves removing the kernel
from each process's address space. This means that every system call
potentially involves cache/TLB invalidation, so applications that are
heavy on system calls like TSM are likely to see more of a performance
impact than entirely CPU-bound applications.

That said, we've applied the RHEL6 patches and haven't had trouble meeting
our backup windows. We did buy TSM servers with more CPU than we thought we
would need, which might help given that TSM is multi-threaded --- each
thread might run more slowly but at least we have other CPUs that can run
other threads.

We're almost an entirely Linux x86_64 shop, so I don't know the impact on other
platforms.

On Tue, Jan 23, 2018 at 08:29:17AM +0100, Stefan Folkerts wrote:
> Hi,
>
> Has anybody seen any information from IBM in relation to Spectre & Meltdown
> patching for Spectrum Protect servers?
> We have a customer who has found that systems that do lot's of small IO's
> that performance can drop 50% on intel systems, these were seen with
> synthetic benchmarks, not actual load.
>
> So this was certainly not a Spectrum Protect load but I was thinking that
> Spectrum Protect might fall into the category that can experience some sort
> of performance drop when patched for Spectre and Meltdown.
>
> Does anybody know what is the impact of these patches on Spectrum Protect
> systems?
>
> Will the blueprints need to be adjusted for instance or is there some
> percentage of lower performance we should expect after patching and does it
> vary per platform?
>
> Regards,
>    Stefan

--
-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine