Evalua&ng the Feasibility of Using Memory Content - - PowerPoint PPT Presentation

evalua ng the feasibility of using memory content
SMART_READER_LITE
LIVE PREVIEW

Evalua&ng the Feasibility of Using Memory Content - - PowerPoint PPT Presentation

Department of Computer Science Evalua&ng the Feasibility of Using Memory Content Similarity to Improve System Resilience Sco> Levy, Kurt B. Ferreira, Patrick G.


slide-1
SLIDE 1

Department of Computer Science

Evalua&ng ¡the ¡Feasibility ¡of ¡Using ¡ Memory ¡Content ¡Similarity ¡to ¡ Improve ¡System ¡Resilience ¡ ¡

Sco> ¡Levy, ¡Kurt ¡B. ¡Ferreira, ¡Patrick ¡G. ¡Bridges, ¡ ¡ Aidan ¡P. ¡Thompson ¡and ¡Chris&an ¡Tro> ¡

slide-2
SLIDE 2

Scalable Systems Lab

} In ¡large-­‑scale ¡systems, ¡errors ¡are ¡propor&onal ¡to ¡socket ¡

count ¡

} Current ¡systems ¡have ¡10s ¡of ¡1000s ¡of ¡sockets; ¡the ¡first ¡

exascale ¡system ¡will ¡have ¡100s ¡of ¡1000s ¡of ¡sockets ¡

} Tradi&onal ¡resilience ¡strategies ¡(e.g., ¡coordinated ¡

checkpoint/restart) ¡mean ¡that ¡less ¡and ¡less ¡&me ¡is ¡ spent ¡doing ¡actual ¡work ¡

} Either: ¡(a) ¡develop ¡more ¡efficient ¡ways ¡to ¡recover ¡from ¡

failure; ¡or ¡(b) ¡reduce ¡the ¡rate ¡at ¡which ¡errors ¡lead ¡to ¡ failure ¡

Resilience ¡Ma+ers ¡

slide-3
SLIDE 3

Scalable Systems Lab

} One ¡of ¡the ¡most ¡common ¡sources ¡of ¡node ¡failure ¡is ¡

memory ¡errors ¡

} On ¡an ¡x86 ¡system, ¡a ¡DRAM ¡ECC ¡error ¡results ¡in ¡a ¡

machine ¡check ¡excep&on ¡(MCE) ¡

} The ¡consequence ¡of ¡an ¡MCE ¡varies ¡by ¡opera&ng ¡system ¡ } In ¡modern ¡Linux, ¡several ¡mi&ga&on ¡strategies ¡are ¡

employed ¡

} If ¡none ¡of ¡these ¡strategies ¡work, ¡the ¡kernel ¡terminates ¡

the ¡applica&on(s) ¡that ¡have ¡the ¡faulted ¡page ¡mapped ¡ into ¡their ¡address ¡space ¡ ¡

DRAM ¡Errors ¡

slide-4
SLIDE 4

Scalable Systems Lab

} DUPLICATE ¡: ¡pages ¡with ¡at ¡least ¡on ¡non-­‑zero ¡byte ¡whose ¡

contents ¡match ¡at ¡least ¡one ¡other ¡page ¡

} ZERO ¡: ¡all-­‑zero ¡pages ¡ } SIMILAR ¡: ¡pages ¡that ¡: ¡(a) ¡are ¡neither ¡duplicate ¡nor ¡zero; ¡and ¡

(b) ¡can ¡be ¡paired ¡with ¡a ¡another ¡page ¡such ¡that ¡the ¡difference ¡ between ¡the ¡two ¡can ¡be ¡compactly ¡represented ¡

} UNIQUE: ¡all ¡other ¡pages ¡

For ¡the ¡data ¡presented ¡here, ¡"compactly ¡represented" ¡means ¡a ¡

cxbsdiff ¡patch ¡that ¡is ¡smaller ¡than ¡1024 ¡bytes ¡

Page ¡Categories ¡

slide-5
SLIDE 5

Scalable Systems Lab

¡ ¡

Begin with uncorrupted block of memory in which we've colored memory to reflect similarity.

Repairing ¡DRAM ¡ECC ¡Errors ¡

slide-6
SLIDE 6

Scalable Systems Lab

¡ ¡

Begin with uncorrupted block of memory in which we've colored memory to reflect similarity. DRAM ECC error is detected indicating that the contents

  • f memory are no longer valid.

Repairing ¡DRAM ¡ECC ¡Errors ¡

XXX

slide-7
SLIDE 7

Scalable Systems Lab

¡ ¡

Begin with uncorrupted block of memory in which we've colored memory to reflect similarity. DRAM ECC error is detected indicating that the contents

  • f memory are no longer valid.

Using the contents of a similar page in memory we can reconstruct the contents of the corrupted page.

Repairing ¡DRAM ¡ECC ¡Errors ¡

XXX

slide-8
SLIDE 8

Scalable Systems Lab

¡ ¡

Begin with uncorrupted block of memory in which we've colored memory to reflect similarity. DRAM ECC error is detected indicating that the contents

  • f memory are no longer valid.

Using the contents of a similar page in memory we can reconstruct the contents of the corrupted page. After the faulted page has been repaired, the application can continue without requiring a restart.

Repairing ¡DRAM ¡ECC ¡Errors ¡

slide-9
SLIDE 9

Scalable Systems Lab

} Objec&ve ¡is ¡to ¡evaluate ¡feasibility ¡ } Approximate ¡the ¡cost ¡and ¡benefit ¡of ¡exploi&ng ¡

memory ¡content ¡similarity ¡

} BENEFIT ¡: ¡ ¡

  • number ¡of ¡non-­‑unique ¡pages ¡

} COSTS: ¡

  • storage ¡overhead ¡(e.g., ¡patch ¡data) ¡
  • run&me ¡overhead ¡

Evalua8on ¡

slide-10
SLIDE 10

Scalable Systems Lab

ASC ¡Sequoia ¡ Marquee ¡ Performance ¡Codes ¡ AMG ¡ Parallel ¡algebraic ¡mul&grid ¡solver ¡ IRS ¡ Implicit ¡Radia&on ¡Solver; ¡radia&on ¡transport ¡ DOE ¡ ¡ Produc&on ¡ Applica&ons ¡ CTH ¡ Mul&-­‑material, ¡large ¡deforma&on, ¡strong ¡shock ¡ wave, ¡solid ¡mechanics ¡code ¡ LAMMPS ¡ Molecular ¡dynamics ¡simulator ¡ Mantevo ¡ Mini-­‑Applica&ons ¡ HPCCG ¡ Mimics ¡finite ¡element ¡genera&on, ¡assembly ¡and ¡ solu&on ¡for ¡an ¡unstructured ¡grid ¡problem ¡ phdMesh ¡ Mimics ¡the ¡contact ¡search ¡applica&ons ¡in ¡an ¡ explicit ¡finite ¡element ¡applica&on ¡ Miscellaneous ¡ Applica&ons ¡ SAMRAI ¡ Enables ¡applica&on ¡of ¡structured ¡adap&ve ¡mesh ¡ refinement ¡to ¡large-­‑scale ¡mul&-­‑physics ¡problems ¡ ¡ Sweep3D ¡ Neutron ¡transport ¡problem ¡

HPC ¡Applica8on ¡Suite ¡

slide-11
SLIDE 11

Scalable Systems Lab

} Collected ¡memory ¡snapshots ¡using ¡libmemstate, ¡a ¡

library ¡built ¡on ¡the ¡MPI ¡Profiling ¡layer ¡and ¡linked ¡ against ¡our ¡target ¡applica&ons ¡

} ¡Periodically, ¡it ¡wakes ¡up ¡and, ¡based ¡on ¡the ¡contents ¡

  • f ¡/proc/self/maps, ¡copies ¡the ¡applica&on's ¡

memory ¡to ¡persistent ¡storage ¡

} Analysis ¡is ¡performed ¡off-­‑line ¡

Data ¡Collec8on ¡

slide-12
SLIDE 12

Scalable Systems Lab

} Naively, ¡iden&fying ¡similar ¡and ¡duplicate ¡pages ¡is ¡a ¡

O(n2) ¡opera&on ¡

} Hashing ¡can ¡reduce ¡the ¡cost ¡of ¡iden&fying ¡duplicate ¡

pages ¡

} Similar ¡pages ¡are ¡trickier; ¡we ¡borrow ¡from ¡the ¡

Difference ¡Engine ¡

Data ¡Collec8on ¡(cont'd) ¡

slide-13
SLIDE 13

Scalable Systems Lab

Suppose the memory of an application consists of these seven pages

Iden8fying ¡Similarity ¡(cont'd) ¡

slide-14
SLIDE 14

Scalable Systems Lab

Suppose the memory of an application consists of these seven pages During initialization, we choose four random offsets. The 128 byte blocks at each offset is a "signature" of the page

Iden8fying ¡Similarity ¡(cont'd) ¡

slide-15
SLIDE 15

Scalable Systems Lab

We compute patches between

  • ur candidate page and each
  • f the four pages identified

by signature If any of these five patches are smaller than a pre-determined threshold (e.g., 1024 bytes) we classify our candidate page as similar Using hash values, we find up to four pages that match

  • ne or more of the candidate

page's signatures

Iden8fying ¡Similarity ¡(cont'd) ¡

Let's suppose we are trying to determine whether this page is similar to any other page in the application's memory

slide-16
SLIDE 16

Scalable Systems Lab

Using hash values, we find up to four pages that match

  • ne or more of the candidate

page's signatures

Iden8fying ¡Similarity ¡(cont'd) ¡

slide-17
SLIDE 17

Scalable Systems Lab

We compute patches between

  • ur candidate page and each
  • f the four pages identified

by signature

Iden8fying ¡Similarity ¡(cont'd) ¡

patch ¡1 ¡ patch ¡2 ¡ patch ¡4 ¡ patch ¡3 ¡

slide-18
SLIDE 18

Scalable Systems Lab

We also compute a patch between

  • ur candidate page and the page

at the next lowest virtual address

Iden8fying ¡Similarity ¡(cont'd) ¡

patch ¡1 ¡ patch ¡2 ¡ patch ¡4 ¡ patch ¡3 ¡ patch ¡5 ¡

slide-19
SLIDE 19

Scalable Systems Lab

Iden8fying ¡Similarity ¡(cont'd) ¡

patch ¡1 ¡ patch ¡2 ¡ patch ¡4 ¡ patch ¡3 ¡ patch ¡5 ¡ If any of these five patches are smaller than a pre-determined threshold (e.g., 1024 bytes) we classify our candidate page as similar

slide-20
SLIDE 20

Scalable Systems Lab

Prevalence ¡of ¡Similarity ¡

} For ¡5 ¡out ¡of ¡8 ¡applica&ons ¡less ¡than ¡half ¡of ¡their ¡memory ¡is ¡

composed ¡of ¡unique ¡pages ¡

20 40 60 80 100 AMG2006 CTH IRS LAMMPS SAMRAI HPCCG phdMesh Sweep3D Percent of memory pages Duplicate Pages Similar Pages Zero Pages Unique Pages

slide-21
SLIDE 21

Scalable Systems Lab

0.05 0.1 0.15 0.2 0.25 0.3 0.35 LJ EAM Rhodo SNAP Fraction of memory pages Similar Pages Duplicate Pages

Inputs ¡ma+er ¡(LAMMPS) ¡

slide-22
SLIDE 22

Scalable Systems Lab

Inputs ¡ma+er ¡(CTH) ¡

10 20 30 40 50 Conical Charge Fragmenting Pipe Percent of memory pages Similar Pages Duplicate Pages

slide-23
SLIDE 23

Scalable Systems Lab

Metadata ¡Overhead ¡

¡ ¡

} The ¡patch ¡data ¡for ¡6 ¡out ¡of ¡8 ¡applica&ons ¡occupies ¡less ¡than ¡

1.5% ¡of ¡applica&on ¡memory ¡

Application Metadata Size

(as % of application memory)

AMG2006 3.99 % CTH 0.31 % IRS 0.57 % LAMMPS 1.34 % SAMRAI 1.36 % HPCCG 1.15 % phdMesh 5.81 % Sweep3D 0.46 %

slide-24
SLIDE 24

Scalable Systems Lab

Metadata ¡Overhead ¡(cont'd) ¡

20 40 60 80 100 5 10 15 20 25 30 Percent of Similar and Duplicate Pages Metadata Size (percent of application memory) AMG2006 phdMesh IRS 1024 byte threshold

slide-25
SLIDE 25

Scalable Systems Lab

¡

} In ¡the ¡memory ¡of ¡5 ¡out ¡of ¡8 ¡applica&ons, ¡more ¡than ¡84% ¡of ¡

the ¡duplicate ¡& ¡similar ¡pages ¡change ¡either ¡once ¡or ¡not ¡at ¡all ¡

Modifica8on ¡Behavior ¡

20 40 60 80 100 AMG2006 CTH IRS LAMMPS SAMRAI HPCCG phdMesh Sweep3D Percent of similar and duplicate pages Zero modifications One modification

slide-26
SLIDE 26

Scalable Systems Lab

} The ¡results ¡are ¡promising ¡ } For ¡many ¡applica&ons, ¡we ¡can ¡poten&ally ¡protect ¡a ¡

significant ¡frac&on ¡of ¡the ¡memory ¡footprint ¡

} Based ¡on ¡our ¡ini&al ¡examina&on, ¡the ¡overhead ¡of ¡

storing ¡and ¡maintaining ¡metadata ¡appear ¡reasonable ¡

} More ¡detail ¡in: ¡An ¡Examina3on ¡of ¡Content ¡Similarity ¡

within ¡the ¡Memory ¡of ¡HPC ¡Applica3ons, ¡ SAND2013-­‑005 ¡

Conclusion ¡

slide-27
SLIDE 27

Scalable Systems Lab

Ques8ons? ¡

slevy@cs.unm.edu ¡