Intro and Related Works
This commit is contained in:
parent
c7a6ff7d03
commit
819f5ead5d
@ -1,3 +1,47 @@
|
||||
@book{hursey2010coordinated,
|
||||
title={Coordinated checkpoint/restart process fault tolerance for MPI applications on HPC systems},
|
||||
author={Hursey, Joshua},
|
||||
year={2010},
|
||||
publisher={Indiana University}
|
||||
}
|
||||
|
||||
@misc{dmtcp,
|
||||
title={DMTCP: Transparent Checkpointing for Cluster Computations and the Desktop},
|
||||
author={Jason Ansel and Kapil Arya and Gene Cooperman},
|
||||
year={2009},
|
||||
eprint={cs/0701037},
|
||||
archivePrefix={arXiv},
|
||||
primaryClass={cs.DC}
|
||||
}
|
||||
|
||||
@article{BLCR,
|
||||
title = {Requirements for Linux Checkpoint/Restart},
|
||||
author = {Duell, Jason and Hargrove, Paul H and Roman, Eric S},
|
||||
doi = {10.2172/793773},
|
||||
url = {https://www.osti.gov/biblio/793773},
|
||||
place = {United States},
|
||||
year = {2002},
|
||||
month = {2}
|
||||
}
|
||||
|
||||
@INPROCEEDINGS{CR-Survey,
|
||||
author={Shahzad, Faisal and Wittmann, Markus and Zeiser, Thomas and Hager, Georg and Wellein, Gerhard},
|
||||
booktitle={2013 IEEE International Symposium on Parallel and Distributed Processing, Workshops and Phd Forum},
|
||||
title={An Evaluation of Different I/O Techniques for Checkpoint/Restart},
|
||||
year={2013},
|
||||
pages={1708-1716},
|
||||
doi={10.1109/IPDPSW.2013.145}
|
||||
}
|
||||
|
||||
@INPROCEEDINGS{SCR,
|
||||
author={Moody, Adam and Bronevetsky, Greg and Mohror, Kathryn and Supinski, Bronis R. de},
|
||||
booktitle={SC '10: Proceedings of the 2010 ACM/IEEE International Conference for High Performance Computing, Networking, Storage and Analysis},
|
||||
title={Design, Modeling, and Evaluation of a Scalable Multi-level Checkpointing System},
|
||||
year={2010},
|
||||
pages={1-11},
|
||||
doi={10.1109/SC.2010.18}
|
||||
}
|
||||
|
||||
|
||||
@misc{noauthor_parmetis_nodate,
|
||||
title = {{ParMETIS} - {Parallel} {Graph} {Partitioning} and {Fill}-reducing {Matrix} {Ordering} {\textbar} {Karypis} {Lab}},
|
||||
@ -73,12 +117,10 @@
|
||||
volume = {01-03-June},
|
||||
issn = {9781450343619},
|
||||
doi = {10.1145/2925426.2926254},
|
||||
abstract = {Searches on large graphs are heavily memory latency bound, as a result of many high latency DRAM accesses. Due to the highly irregular nature of the access patterns involved, caches and prefetchers, both hardware and software, perform poorly on graph workloads. This leads to CPU stalling for the majority of the time. However, in many cases the data access pattern is well defined and predictable in advance, many falling into a small set of simple patterns. Although existing implicit prefetchers cannot bring significant benefit, a prefetcher armed with knowledge of the data structures and access patterns could accurately anticipate applications' traversals to bring in the appropriate data. This paper presents a design of an explicitly configured prefetcher to improve performance for breadth-first searches and sequential iteration on the efficient and commonly-used compressed sparse row graph format. By snooping L1 cache accesses from the core and reacting to data returned from its own prefetches, the prefetcher can schedule timely loads of data in advance of the application needing it. For a range of applications and graph sizes, our prefetcher achieves average speedups of 2.3×, and up to 3.3×, with little impact on memory bandwidth requirements.},
|
||||
journal = {Proceedings of the International Conference on Supercomputing},
|
||||
author = {Ainsworth, Sam and Jones, Timothy M.},
|
||||
year = {2016},
|
||||
keywords = {Graphs, Prefetching},
|
||||
file = {Graph Prefetching Using Data Structure Knowledge:/home/noah/Zotero/storage/UUVEP42L/Graph Prefetching Using Data Structure Knowledge.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@article{albanese_graphical_2018,
|
||||
|
||||
@ -15,35 +15,58 @@
|
||||
\gdef\HyperFirstAtBeginDocument#1{#1}
|
||||
\providecommand\HyField@AuxAddToFields[1]{}
|
||||
\providecommand\HyField@AuxAddToCoFields[2]{}
|
||||
\citation{schneier_modeling_1999}
|
||||
\citation{j_hale_compliance_nodate}
|
||||
\citation{cook_rage_2018}
|
||||
\citation{berry_graph_2007}
|
||||
\citation{berry_graph_2007}
|
||||
\citation{zhang_boosting_2017}
|
||||
\citation{ainsworth_graph_2016}
|
||||
\citation{berry_graph_2007}
|
||||
\citation{ainsworth_graph_2016}
|
||||
\citation{cook_rage_2018}
|
||||
\citation{cook_rage_2018}
|
||||
\citation{ou_scalable_2006}
|
||||
\citation{CR-Survey}
|
||||
\citation{hursey2010coordinated}
|
||||
\citation{SCR}
|
||||
\citation{dmtcp}
|
||||
\citation{BLCR}
|
||||
\babel@aux{nil}{}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {I}Introduction}{1}{section.1}\protected@file@percent }
|
||||
\newlabel{sec:Intro}{{I}{1}{Introduction}{section.1}{}}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {II}Related Work}{1}{section.2}\protected@file@percent }
|
||||
\newlabel{sec:Rel-Works}{{II}{1}{Related Work}{section.2}{}}
|
||||
\citation{ou_scalable_2006}
|
||||
\citation{cook_scalable_2016}
|
||||
\citation{li_concurrency_2019}
|
||||
\citation{cook_rage_2018}
|
||||
\citation{li_concurrency_2019}
|
||||
\citation{li_combining_2019}
|
||||
\citation{zhang_boosting_2017}
|
||||
\citation{ainsworth_graph_2016}
|
||||
\citation{berry_graph_2007}
|
||||
\citation{cook_rage_2018}
|
||||
\citation{zhang_boosting_2017}
|
||||
\babel@aux{nil}{}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {I}Introduction}{1}{section.1}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {II}Related Work}{1}{section.2}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {III}Implementing C/R}{1}{section.3}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-A}}Introduction to Intermediate Database Storage}{1}{subsection.3.1}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-B}}Memory Constraint Difficulties}{1}{subsection.3.2}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {III}Implementation}{2}{section.3}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-A}}Memory Constraint Difficulties}{2}{subsection.3.1}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-B}}Checkpointing}{2}{subsection.3.2}\protected@file@percent }
|
||||
\bibdata{Bibliography}
|
||||
\bibcite{cook_rage_2018}{1}
|
||||
\bibcite{li_concurrency_2019}{2}
|
||||
\bibcite{li_combining_2019}{3}
|
||||
\bibcite{zhang_boosting_2017}{4}
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-C}}Maximizing Performance with Intermediate Database Storage}{2}{subsection.3.3}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-D}}Portability}{2}{subsection.3.4}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-E}}Implementation Approach}{2}{subsection.3.5}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-F}}Implementation Challenges}{2}{subsection.3.6}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {IV}Results}{2}{section.4}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {V}Conclusion}{2}{section.5}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{References}{2}{section*.3}\protected@file@percent }
|
||||
\bibcite{ainsworth_graph_2016}{5}
|
||||
\bibcite{berry_graph_2007}{6}
|
||||
\bibcite{schneier_modeling_1999}{1}
|
||||
\bibcite{j_hale_compliance_nodate}{2}
|
||||
\bibcite{cook_rage_2018}{3}
|
||||
\bibcite{berry_graph_2007}{4}
|
||||
\bibcite{zhang_boosting_2017}{5}
|
||||
\bibcite{ainsworth_graph_2016}{6}
|
||||
\bibcite{ou_scalable_2006}{7}
|
||||
\bibcite{CR-Survey}{8}
|
||||
\bibcite{hursey2010coordinated}{9}
|
||||
\bibcite{SCR}{10}
|
||||
\bibcite{dmtcp}{11}
|
||||
\bibcite{BLCR}{12}
|
||||
\bibcite{cook_scalable_2016}{13}
|
||||
\bibcite{li_concurrency_2019}{14}
|
||||
\bibcite{li_combining_2019}{15}
|
||||
\bibstyle{ieeetr}
|
||||
\@writefile{toc}{\contentsline {subsubsection}{\numberline {\mbox {III-B}1}Portability}{3}{subsubsection.3.2.1}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-C}}Restarting}{3}{subsection.3.3}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {IV}Results}{3}{section.4}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {V}Conclusions and Future Work}{3}{section.5}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{References}{3}{section*.1}\protected@file@percent }
|
||||
\gdef \@abspage@last{3}
|
||||
|
||||
@ -1,18 +1,21 @@
|
||||
\begin{thebibliography}{1}
|
||||
\begin{thebibliography}{10}
|
||||
|
||||
\bibitem{schneier_modeling_1999}
|
||||
B.~Schneier, ``Modeling {Security} {Threats},'' {\em Dr. Dobb's Journal}, 1999.
|
||||
\newblock vol. 24, no.12.
|
||||
|
||||
\bibitem{j_hale_compliance_nodate}
|
||||
{J. Hale}, P.~Hawrylak, and M.~Papa, ``Compliance {Method} for a
|
||||
{Cyber}-{Physical} {System}.''
|
||||
\newblock U.S. Patent Number 9,471,789, Oct. 18, 2016.
|
||||
|
||||
\bibitem{cook_rage_2018}
|
||||
K.~Cook, {\em {RAGE}: {The} {Rage} {Attack} {Graph} {Engine}}.
|
||||
\newblock PhD thesis, The {University} of {Tulsa}, 2018.
|
||||
|
||||
\bibitem{li_concurrency_2019}
|
||||
M.~Li, P.~Hawrylak, and J.~Hale, ``Concurrency {Strategies} for {Attack}
|
||||
{Graph} {Generation},'' {\em Proceedings - 2019 2nd International Conference
|
||||
on Data Intelligence and Security, ICDIS 2019}, pp.~174--179, 2019.
|
||||
|
||||
\bibitem{li_combining_2019}
|
||||
M.~Li, P.~Hawrylak, and J.~Hale, ``Combining {OpenCL} and {MPI} to support
|
||||
heterogeneous computing on a cluster,'' {\em ACM International Conference
|
||||
Proceeding Series}, 2019.
|
||||
\bibitem{berry_graph_2007}
|
||||
J.~Berry and B.~Hendrickson, ``Graph {Analysis} with {High} {Performance}
|
||||
{Computing}.,'' {\em Computing in Science and Engineering}, 2007.
|
||||
|
||||
\bibitem{zhang_boosting_2017}
|
||||
J.~Zhang, S.~Khoram, and J.~Li, ``Boosting the performance of {FPGA}-based
|
||||
@ -25,8 +28,49 @@ S.~Ainsworth and T.~M. Jones, ``Graph prefetching using data structure
|
||||
knowledge,'' {\em Proceedings of the International Conference on
|
||||
Supercomputing}, vol.~01-03-June, 2016.
|
||||
|
||||
\bibitem{berry_graph_2007}
|
||||
J.~Berry and B.~Hendrickson, ``Graph {Analysis} with {High} {Performance}
|
||||
{Computing}.,'' {\em Computing in Science and Engineering}, 2007.
|
||||
\bibitem{ou_scalable_2006}
|
||||
X.~Ou, W.~F. Boyer, and M.~A. Mcqueen, ``A {Scalable} {Approach} to {Attack}
|
||||
{Graph} {Generation},'' {\em CCS '06: Proceedings of the 13th ACM conference
|
||||
on Computer and communications security}, pp.~336--345, 2006.
|
||||
|
||||
\bibitem{CR-Survey}
|
||||
F.~Shahzad, M.~Wittmann, T.~Zeiser, G.~Hager, and G.~Wellein, ``An evaluation
|
||||
of different i/o techniques for checkpoint/restart,'' in {\em 2013 IEEE
|
||||
International Symposium on Parallel and Distributed Processing, Workshops and
|
||||
Phd Forum}, pp.~1708--1716, 2013.
|
||||
|
||||
\bibitem{hursey2010coordinated}
|
||||
J.~Hursey, {\em Coordinated checkpoint/restart process fault tolerance for MPI
|
||||
applications on HPC systems}.
|
||||
\newblock Indiana University, 2010.
|
||||
|
||||
\bibitem{SCR}
|
||||
A.~Moody, G.~Bronevetsky, K.~Mohror, and B.~R.~d. Supinski, ``Design, modeling,
|
||||
and evaluation of a scalable multi-level checkpointing system,'' in {\em SC
|
||||
'10: Proceedings of the 2010 ACM/IEEE International Conference for High
|
||||
Performance Computing, Networking, Storage and Analysis}, pp.~1--11, 2010.
|
||||
|
||||
\bibitem{dmtcp}
|
||||
J.~Ansel, K.~Arya, and G.~Cooperman, ``Dmtcp: Transparent checkpointing for
|
||||
cluster computations and the desktop,'' 2009.
|
||||
|
||||
\bibitem{BLCR}
|
||||
J.~Duell, P.~H. Hargrove, and E.~S. Roman, ``Requirements for linux
|
||||
checkpoint/restart,'' 2 2002.
|
||||
|
||||
\bibitem{cook_scalable_2016}
|
||||
K.~Cook, T.~Shaw, J.~Hale, and P.~Hawrylak, ``Scalable attack graph
|
||||
generation,'' {\em Proceedings of the 11th Annual Cyber and Information
|
||||
Security Research Conference, CISRC 2016}, 2016.
|
||||
|
||||
\bibitem{li_concurrency_2019}
|
||||
M.~Li, P.~Hawrylak, and J.~Hale, ``Concurrency {Strategies} for {Attack}
|
||||
{Graph} {Generation},'' {\em Proceedings - 2019 2nd International Conference
|
||||
on Data Intelligence and Security, ICDIS 2019}, pp.~174--179, 2019.
|
||||
|
||||
\bibitem{li_combining_2019}
|
||||
M.~Li, P.~Hawrylak, and J.~Hale, ``Combining {OpenCL} and {MPI} to support
|
||||
heterogeneous computing on a cluster,'' {\em ACM International Conference
|
||||
Proceeding Series}, 2019.
|
||||
|
||||
\end{thebibliography}
|
||||
|
||||
@ -3,44 +3,46 @@ Capacity: max_strings=200000, hash_size=200000, hash_prime=170003
|
||||
The top-level auxiliary file: Schrick-Noah_AG-CG-CR.aux
|
||||
The style file: ieeetr.bst
|
||||
Database file #1: Bibliography.bib
|
||||
You've used 6 entries,
|
||||
Warning--empty journal in BLCR
|
||||
You've used 15 entries,
|
||||
1876 wiz_defined-function locations,
|
||||
508 strings with 4595 characters,
|
||||
and the built_in function-call counts, 1281 in all, are:
|
||||
= -- 124
|
||||
> -- 53
|
||||
556 strings with 6253 characters,
|
||||
and the built_in function-call counts, 3258 in all, are:
|
||||
= -- 298
|
||||
> -- 150
|
||||
< -- 0
|
||||
+ -- 20
|
||||
- -- 14
|
||||
* -- 83
|
||||
:= -- 201
|
||||
add.period$ -- 7
|
||||
call.type$ -- 6
|
||||
change.case$ -- 5
|
||||
+ -- 56
|
||||
- -- 41
|
||||
* -- 211
|
||||
:= -- 489
|
||||
add.period$ -- 18
|
||||
call.type$ -- 15
|
||||
change.case$ -- 13
|
||||
chr.to.int$ -- 0
|
||||
cite$ -- 6
|
||||
duplicate$ -- 68
|
||||
empty$ -- 123
|
||||
format.name$ -- 14
|
||||
if$ -- 303
|
||||
cite$ -- 16
|
||||
duplicate$ -- 168
|
||||
empty$ -- 330
|
||||
format.name$ -- 41
|
||||
if$ -- 786
|
||||
int.to.chr$ -- 0
|
||||
int.to.str$ -- 6
|
||||
missing$ -- 5
|
||||
newline$ -- 22
|
||||
num.names$ -- 6
|
||||
pop$ -- 19
|
||||
int.to.str$ -- 15
|
||||
missing$ -- 13
|
||||
newline$ -- 52
|
||||
num.names$ -- 15
|
||||
pop$ -- 69
|
||||
preamble$ -- 1
|
||||
purify$ -- 0
|
||||
quote$ -- 0
|
||||
skip$ -- 35
|
||||
skip$ -- 87
|
||||
stack$ -- 0
|
||||
substring$ -- 64
|
||||
swap$ -- 22
|
||||
substring$ -- 147
|
||||
swap$ -- 50
|
||||
text.length$ -- 0
|
||||
text.prefix$ -- 0
|
||||
top$ -- 0
|
||||
type$ -- 0
|
||||
warning$ -- 0
|
||||
while$ -- 12
|
||||
width$ -- 7
|
||||
write$ -- 55
|
||||
warning$ -- 1
|
||||
while$ -- 28
|
||||
width$ -- 17
|
||||
write$ -- 131
|
||||
(There was 1 warning)
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Arch Linux) (preloaded format=pdflatex 2023.4.3) 22 APR 2023 20:22
|
||||
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Arch Linux) (preloaded format=pdflatex 2023.4.3) 23 APR 2023 16:27
|
||||
entering extended mode
|
||||
restricted \write18 enabled.
|
||||
%&-line parsing enabled.
|
||||
@ -484,42 +484,57 @@ Package hyperref Info: Link coloring ON on input line 24.
|
||||
\openout3 = `Schrick-Noah_AG-CG-CR.out'.
|
||||
|
||||
|
||||
Underfull \hbox (badness 1496) in paragraph at lines 58--59
|
||||
\OT1/ptm/m/n/10 of attack graph generation in regards to its scalability.
|
||||
Underfull \hbox (badness 2158) in paragraph at lines 55--62
|
||||
[]\OT1/ptm/m/n/10 Despite their advantages, graph generation has many
|
||||
[]
|
||||
|
||||
[1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}{/usr/share/texmf-dist/fon
|
||||
ts/enc/dvips/base/8r.enc}
|
||||
|
||||
Underfull \hbox (badness 2941) in paragraph at lines 79--79
|
||||
\OT1/ptm/m/it/10 C. Maximizing Performance with Intermediate Database
|
||||
[]
|
||||
|
||||
LaTeX Font Info: Trying to load font information for U+msa on input line 82.
|
||||
]
|
||||
LaTeX Font Info: Trying to load font information for U+msa on input line 72.
|
||||
|
||||
(/usr/share/texmf-dist/tex/latex/amsfonts/umsa.fd
|
||||
(/usr/share/texmf-dist/tex/latex/amsfonts/umsa.fd
|
||||
File: umsa.fd 2013/01/14 v3.01 AMS symbols A
|
||||
)
|
||||
LaTeX Font Info: Trying to load font information for U+msb on input line 82.
|
||||
LaTeX Font Info: Trying to load font information for U+msb on input line 72.
|
||||
|
||||
|
||||
(/usr/share/texmf-dist/tex/latex/amsfonts/umsb.fd
|
||||
File: umsb.fd 2013/01/14 v3.01 AMS symbols B
|
||||
)
|
||||
Underfull \vbox (badness 10000) has occurred while \output is active []
|
||||
|
||||
[1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}{/usr/share/texmf-dist/fo
|
||||
nts/enc/dvips/base/8r.enc}
|
||||
|
||||
|
||||
]
|
||||
Underfull \hbox (badness 3343) in paragraph at lines 97--101
|
||||
[]\OT1/ptm/m/n/10 However, a new issue arose with database storage.
|
||||
Underfull \hbox (badness 1552) in paragraph at lines 70--75
|
||||
\OT1/ptm/m/n/10 compliance graphs attempt to improve performance and
|
||||
[]
|
||||
|
||||
(./Schrick-Noah_AG-CG-CR.bbl [2]
|
||||
Underfull \hbox (badness 3386) in paragraph at lines 24--27
|
||||
|
||||
Underfull \hbox (badness 1960) in paragraph at lines 70--75
|
||||
\OT1/ptm/m/n/10 scalability to mitigate state space explosion or lengthy
|
||||
[]
|
||||
|
||||
[2]
|
||||
Underfull \hbox (badness 4660) in paragraph at lines 117--122
|
||||
\OT1/ptm/m/it/10 1) Portability: [][][] \OT1/ptm/m/n/10 The checkpointing proc
|
||||
ess is greatly
|
||||
[]
|
||||
|
||||
(./Schrick-Noah_AG-CG-CR.bbl
|
||||
Underfull \hbox (badness 2351) in paragraph at lines 27--30
|
||||
[]\OT1/ptm/m/n/8 S. Ainsworth and T. M. Jones, ``Graph prefetching using data
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 1616) in paragraph at lines 48--52
|
||||
\OT1/ptm/m/n/8 modeling, and evaluation of a scalable multi-level checkpointing
|
||||
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 5091) in paragraph at lines 54--56
|
||||
[]\OT1/ptm/m/n/8 J. Ansel, K. Arya, and G. Cooperman, ``Dmtcp: Transparent
|
||||
[]
|
||||
|
||||
)
|
||||
|
||||
** Conference Paper **
|
||||
@ -532,28 +547,29 @@ Before submitting the final camera ready copy, remember to:
|
||||
uses only Type 1 fonts and that every step in the generation
|
||||
process uses the appropriate paper size.
|
||||
|
||||
[3
|
||||
|
||||
] (./Schrick-Noah_AG-CG-CR.aux)
|
||||
[3] (./Schrick-Noah_AG-CG-CR.aux)
|
||||
Package rerunfilecheck Info: File `Schrick-Noah_AG-CG-CR.out' has not changed.
|
||||
(rerunfilecheck) Checksum: C307A791803EA9C782F9DEB32BA6EA45;1939.
|
||||
(rerunfilecheck) Checksum: 6E2DC49B6AC85A528B419E5F14917A57;1246.
|
||||
)
|
||||
Here is how much of TeX's memory you used:
|
||||
12010 strings out of 476025
|
||||
189795 string characters out of 5796533
|
||||
1872388 words of memory out of 5000000
|
||||
32284 multiletter control sequences out of 15000+600000
|
||||
12024 strings out of 476025
|
||||
190058 string characters out of 5796533
|
||||
1871388 words of memory out of 5000000
|
||||
32293 multiletter control sequences out of 15000+600000
|
||||
544489 words of font info for 89 fonts, out of 8000000 for 9000
|
||||
1141 hyphenation exceptions out of 8191
|
||||
75i,8n,76p,1314b,588s stack positions out of 5000i,500n,10000p,200000b,80000s
|
||||
75i,8n,76p,1314b,452s stack positions out of 5000i,500n,10000p,200000b,80000s
|
||||
</usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb></usr/share/
|
||||
texmf-dist/fonts/type1/urw/times/utmb8a.pfb></usr/share/texmf-dist/fonts/type1/
|
||||
urw/times/utmbi8a.pfb></usr/share/texmf-dist/fonts/type1/urw/times/utmr8a.pfb><
|
||||
/usr/share/texmf-dist/fonts/type1/urw/times/utmri8a.pfb>
|
||||
Output written on Schrick-Noah_AG-CG-CR.pdf (3 pages, 80097 bytes).
|
||||
texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb></usr/share/texmf-dist/font
|
||||
s/type1/public/amsfonts/cm/cmr7.pfb></usr/share/texmf-dist/fonts/type1/public/a
|
||||
msfonts/cm/cmsy10.pfb></usr/share/texmf-dist/fonts/type1/urw/times/utmb8a.pfb><
|
||||
/usr/share/texmf-dist/fonts/type1/urw/times/utmbi8a.pfb></usr/share/texmf-dist/
|
||||
fonts/type1/urw/times/utmr8a.pfb></usr/share/texmf-dist/fonts/type1/urw/times/u
|
||||
tmri8a.pfb>
|
||||
Output written on Schrick-Noah_AG-CG-CR.pdf (3 pages, 110939 bytes).
|
||||
PDF statistics:
|
||||
119 PDF objects out of 1000 (max. 8388607)
|
||||
102 compressed objects within 2 object streams
|
||||
24 named destinations out of 1000 (max. 500000)
|
||||
97 words of extra memory for PDF output out of 10000 (max. 10000000)
|
||||
148 PDF objects out of 1000 (max. 8388607)
|
||||
125 compressed objects within 2 object streams
|
||||
29 named destinations out of 1000 (max. 500000)
|
||||
81 words of extra memory for PDF output out of 10000 (max. 10000000)
|
||||
|
||||
|
||||
@ -1,12 +1,10 @@
|
||||
\BOOKMARK [1][-]{section.1}{\376\377\000I\000n\000t\000r\000o\000d\000u\000c\000t\000i\000o\000n}{}% 1
|
||||
\BOOKMARK [1][-]{section.2}{\376\377\000R\000e\000l\000a\000t\000e\000d\000\040\000W\000o\000r\000k}{}% 2
|
||||
\BOOKMARK [1][-]{section.3}{\376\377\000I\000m\000p\000l\000e\000m\000e\000n\000t\000i\000n\000g\000\040\000C\000/\000R}{}% 3
|
||||
\BOOKMARK [2][-]{subsection.3.1}{\376\377\000I\000n\000t\000r\000o\000d\000u\000c\000t\000i\000o\000n\000\040\000t\000o\000\040\000I\000n\000t\000e\000r\000m\000e\000d\000i\000a\000t\000e\000\040\000D\000a\000t\000a\000b\000a\000s\000e\000\040\000S\000t\000o\000r\000a\000g\000e}{section.3}% 4
|
||||
\BOOKMARK [2][-]{subsection.3.2}{\376\377\000M\000e\000m\000o\000r\000y\000\040\000C\000o\000n\000s\000t\000r\000a\000i\000n\000t\000\040\000D\000i\000f\000f\000i\000c\000u\000l\000t\000i\000e\000s}{section.3}% 5
|
||||
\BOOKMARK [2][-]{subsection.3.3}{\376\377\000M\000a\000x\000i\000m\000i\000z\000i\000n\000g\000\040\000P\000e\000r\000f\000o\000r\000m\000a\000n\000c\000e\000\040\000w\000i\000t\000h\000\040\000I\000n\000t\000e\000r\000m\000e\000d\000i\000a\000t\000e\000\040\000D\000a\000t\000a\000b\000a\000s\000e\000\040\000S\000t\000o\000r\000a\000g\000e}{section.3}% 6
|
||||
\BOOKMARK [2][-]{subsection.3.4}{\376\377\000P\000o\000r\000t\000a\000b\000i\000l\000i\000t\000y}{section.3}% 7
|
||||
\BOOKMARK [2][-]{subsection.3.5}{\376\377\000I\000m\000p\000l\000e\000m\000e\000n\000t\000a\000t\000i\000o\000n\000\040\000A\000p\000p\000r\000o\000a\000c\000h}{section.3}% 8
|
||||
\BOOKMARK [2][-]{subsection.3.6}{\376\377\000I\000m\000p\000l\000e\000m\000e\000n\000t\000a\000t\000i\000o\000n\000\040\000C\000h\000a\000l\000l\000e\000n\000g\000e\000s}{section.3}% 9
|
||||
\BOOKMARK [1][-]{section.4}{\376\377\000R\000e\000s\000u\000l\000t\000s}{}% 10
|
||||
\BOOKMARK [1][-]{section.5}{\376\377\000C\000o\000n\000c\000l\000u\000s\000i\000o\000n}{}% 11
|
||||
\BOOKMARK [1][-]{section*.3}{\376\377\000R\000e\000f\000e\000r\000e\000n\000c\000e\000s}{}% 12
|
||||
\BOOKMARK [1][-]{section.3}{\376\377\000I\000m\000p\000l\000e\000m\000e\000n\000t\000a\000t\000i\000o\000n}{}% 3
|
||||
\BOOKMARK [2][-]{subsection.3.1}{\376\377\000M\000e\000m\000o\000r\000y\000\040\000C\000o\000n\000s\000t\000r\000a\000i\000n\000t\000\040\000D\000i\000f\000f\000i\000c\000u\000l\000t\000i\000e\000s}{section.3}% 4
|
||||
\BOOKMARK [2][-]{subsection.3.2}{\376\377\000C\000h\000e\000c\000k\000p\000o\000i\000n\000t\000i\000n\000g}{section.3}% 5
|
||||
\BOOKMARK [3][-]{subsubsection.3.2.1}{\376\377\000P\000o\000r\000t\000a\000b\000i\000l\000i\000t\000y}{subsection.3.2}% 6
|
||||
\BOOKMARK [2][-]{subsection.3.3}{\376\377\000R\000e\000s\000t\000a\000r\000t\000i\000n\000g}{section.3}% 7
|
||||
\BOOKMARK [1][-]{section.4}{\376\377\000R\000e\000s\000u\000l\000t\000s}{}% 8
|
||||
\BOOKMARK [1][-]{section.5}{\376\377\000C\000o\000n\000c\000l\000u\000s\000i\000o\000n\000s\000\040\000a\000n\000d\000\040\000F\000u\000t\000u\000r\000e\000\040\000W\000o\000r\000k}{}% 9
|
||||
\BOOKMARK [1][-]{section*.1}{\376\377\000R\000e\000f\000e\000r\000e\000n\000c\000e\000s}{}% 10
|
||||
|
||||
Binary file not shown.
@ -23,7 +23,7 @@
|
||||
|
||||
\begin{document}
|
||||
|
||||
\title{Checkpoint/Restart for Large-Scale Attack and Compliance Graphs
|
||||
\title{Application-Level Checkpoint/Restart for Large-Scale Attack and Compliance Graphs
|
||||
}
|
||||
|
||||
\author{\IEEEauthorblockN{Noah L. Schrick}
|
||||
@ -50,41 +50,55 @@ Attack Graph; Compliance Graph; MPI; High-Performance Computing; Checkpoint/Rest
|
||||
\end{IEEEkeywords}
|
||||
|
||||
\section{Introduction} \label{sec:Intro}
|
||||
In order to predict and prevent the risk of cyber attacks, various modeling and tabletop approaches are implemented to best prepare for attack scenarios. One approach is through the use of attack graphs, originally presented by the author of \cite{schneier_modeling_1999}. Attack graphs represent possible attack scenarios or vulnerability paths in a network. These graphs consist of nodes and edges, with various information encoded at the topological level as well as within the nodes themselves. Similarly, compliance graphs are used to predict and prevent violations of compliance or regulation mandates \cite{j_hale_compliance_nodate}. These graphs are now generated through the use of attack or compliance generators, rather than by hand. The generator tool used by this work is RAGE (the RAGE Attack Graph Engine) \cite{cook_rage_2018}.
|
||||
|
||||
Despite their advantages, graph generation has many challenges that prevent full actualization of computation seen from a theoretical standpoint, and these challenges extend to attack and compliance graphs.
|
||||
In practice, graph generation often achieves only a very low percentage of its expected performance \cite{berry_graph_2007}. A few reasons
|
||||
for this occurrence lie in the underlying mechanisms of graph generation. The generation is predominantly memory based (as opposed to based on processor speed),
|
||||
where performance is tied to memory access time, the complexity of data dependency, and coarseness of parallelism \cite{berry_graph_2007}, \cite{zhang_boosting_2017},
|
||||
\cite{ainsworth_graph_2016}. Graphs consume large amounts of memory through their
|
||||
nodes and edges, graph data structures suffer from poor cache locality, and memory latency from the processor-memory gap all slow the generation process dramatically
|
||||
\cite{berry_graph_2007}, \cite{ainsworth_graph_2016}.
|
||||
|
||||
The author of \cite{cook_rage_2018} discusses the challenges of attack graph generation in regards to its scalability. Specifically, the author of \cite{cook_rage_2018} displays results from generations based on small networks that result in a large state space. The authors of \cite{ou_scalable_2006} also present the scalability challenges of attack graphs. Their findings indicate that small networks result in graphs with total edges and nodes in the order of millions. Generating an attack or compliance graph based on a large network with a multitude of assets and involving a more thorough exploit or compliance violation checking will prevent the entire graph from being stored in memory as originally designed.
|
||||
|
||||
Due to the runtime requirements and scalability challenges imposed by graph generation, fault-tolerance is critical to ensure reliable generation. These difficulties highlight the need for fault-tolerance and memory relief approaches. The ability to safely checkpoint and recover from a system error is crucial to avoid duplicated work or needing to request more cycles on an HPC cluster. In addition, having the ability to handle the memory strain without requesting excess RAM on an HPC cluster assists in reducing incurred cost. This work presents an application-level checkpoint/restart (C/R) approach tailored to large-scale graph generation. This work illustrates the advantages in having a C/R system built into the generation process itself, rather than using alternative libraries. By having native C/R, performance can be maximized and runtime interruption and overhead can be minimized. This C/R approach allows the user to ensure fault-tolerance for graph generation without the reliance on a system-level, HPC cluster implementation of C/R.
|
||||
|
||||
\section{Related Work} \label{sec:Rel-Works}
|
||||
Numerous efforts have been presented for C/R techniques with various categories available. The authors of \cite{CR-Survey} and \cite{hursey2010coordinated} discuss three categories of C/R, which include application-level, user-level, and system-level. Each approach draws upon advantages that appeal toward different aspects of reliability. Notably, application-level requiring additional work for the implementation but resulting in smaller, faster C/R, user-level with its simplicity, but resulting in larger checkpoints, and system-level requiring compatibility with the operating system and any libraries used for the application. The authors of \cite{SCR} present the SCR (Scalable Checkpoint/Restart) library, which has seen widespread adoption due to its minimal overhead. DMTCP (Distributed MultiThreaded Checkpointing) \cite{dmtcp} and BLCR (Berkely Lab Checkpoint/Restart) \cite{BLCR} are two other commonly-seen C/R approaches.
|
||||
|
||||
Rather than using C/R, investigations into attack and compliance graphs attempt to improve performance and scalability to mitigate state space explosion or lengthy runtimes. As a means of improving scalability of attack graphs themselves, the authors of \cite{ou_scalable_2006} present a new representation scheme. Traditional attack graphs encode the entire network at each state,
|
||||
but the representation presented by the authors uses logical statements to represent a portion of the network at each node. This is called a logical attack graph. This approach led to the reduction of the generation process
|
||||
to quadratic time and reduced the number of nodes in the resulting graph to $\mathcal{O}({n}^2)$. However, this approach does require more analysis for identifying attack vectors. Another approach
|
||||
presented by the authors of \cite{cook_scalable_2016} represents a description of systems and their qualities and topologies as a state, with a queue of unexplored states. This work was continued by the
|
||||
authors of \cite{li_concurrency_2019} by implementing a hash table among other features. Each of these works demonstrates an improvement in scalability through refining the desirable information output.
|
||||
|
||||
\section{Implementation}
|
||||
\subsection{Introduction to Intermediate Database Storage}
|
||||
Chapter 2 and the author of \cite{cook_rage_2018} discuss the challenges of attack graph generation in regards to its scalability. Specifically, the author of \cite{cook_rage_2018} displays results from generations based on 11 assets and 11 exploits that lead to 14,200 total states. Generating an attack or compliance graph based on a large network with a multitude of assets and involving a more thorough exploit or compliance violation checking will prevent the entire graph from being stored in memory as originally designed. This Section discusses the challenges of graph generation in regards to memory, and a solution through the implementation of intermediate database storage.
|
||||
Previous works with RAGE have been designed around maximizing performance to limit the longer runtime caused by the state space explosion, such as the works seen by the authors of \cite{cook_rage_2018},
|
||||
\cite{li_concurrency_2019}, and \cite{li_combining_2019}. To this end, the output graph is contained in memory during the generation process to minimize disk writing and reading. RAGE does incorporate PostgreSQL as an initial and final storage mechanism to write the starting and resulting graph information, but no intermediate storage is otherwise conducted. Based on the inclusion of PostgreSQL in RAGE, the C/R approach was based around this dependency.
|
||||
|
||||
\subsection{Memory Constraint Difficulties}
|
||||
Previous works with RAGE have been designed around maximizing performance to limit the longer runtime caused by the state space explosion, such as the works seen by the authors of \cite{cook_rage_2018},
|
||||
\cite{li_concurrency_2019}, and \cite{li_combining_2019}. To this end, the output graph is contained in memory during the generation process to minimize disk writing and reading. This also allows for leveraging the
|
||||
performance benefits of memory operations, since graph computation relies less on processor speed and more on data dependency complexity, parallelism coarseness, and memory access time
|
||||
\cite{zhang_boosting_2017}, \cite{ainsworth_graph_2016}, \cite{berry_graph_2007}. The author of \cite{cook_rage_2018} does incorporate PostgreSQL as an initial and final storage mechanism to write the starting and resulting
|
||||
graph information, but no intermediate storage is otherwise conducted.
|
||||
|
||||
While the design decision to not use intermediate storage maximizes performance for graph generation, it introduces a few complications. When generating large graphs, the system runs the risk
|
||||
of running out of memory. This typically does not occur when generation is conducted on small graphs, and is especially true when relatively small graphs are generated on an HPC
|
||||
system with substantial amounts of memory. However, when running on local systems or when the graph is large, memory can quickly be depleted due to state space explosion. The memory depletion is due to two primary
|
||||
memory consumption points: the frontier which contains all of the states that still need to be explored, and the graph instance which holds all of the states and their information,
|
||||
as well as all of the edges.
|
||||
|
||||
The frontier quickly becomes a problem point with large graphs that have a large height value, and contain many layers before reaching leaf nodes. During the generation process, RAGE works on a Breadth-First Search approach, and new states
|
||||
are continuously discovered each time a state from the frontier is explored. In almost all cases, this means that for every state that is removed from the frontier, several more are added, leading to an ever-growing
|
||||
The frontier rapidly strains memory with large graphs that have a large height value and contain many layers before the leaf nodes. During the generation process, RAGE works on a Breadth-First Search approach, and new states
|
||||
are continuously discovered each time a state from the frontier is explored. In almost all cases, this means that for every state that is removed from the frontier, several more are added, leading to a rapidly increasing
|
||||
frontier that can not be adequately reduced for large networks. Simultaneously, the graph instance continues to grow as states are explored. When the network contains numerous assets, each with their own large sets of
|
||||
qualities, the size of each state becomes noticeably larger. With some graphs containing millions of nodes and billions of edges like those mentioned by the authors of \cite{zhang_boosting_2017}, it becomes increasingly
|
||||
unlikely that the graph can be fully contained within system memory.
|
||||
unlikely that the graph can be fully contained within system memory. Checkpointing provides an additional benefit to the generation process to relieve its memory strain.
|
||||
|
||||
\subsection{Maximizing Performance with Intermediate Database Storage}
|
||||
Rather than a static implementation of storing to the database on disk at a set interval or a set size, the goal was to dynamically store to the database only when necessary. This would allow for proper utilization of systems with greater memory, and would reduce fine-tuning of a maximum size variable before database writes on different systems. Since there is an associated cost with preparing
|
||||
the writes to disk, the communication cost across nodes, the writing to disk itself, and a cost for retrieving items from disk, it is desirable to store as much in memory for as long as possible and only write when necessary. When
|
||||
running RAGE, a new argument can be passed \textit{(-a $<$double$>$)} to specify the amount of memory the tool should use before writing to disk. This argument is a value between 0 and 0.99 to specify a percentage.
|
||||
This double is immediately reduced by 10\%. For instance, if 0.6 is passed, it is immediately reduced to 0.5. This acts as a buffer for PostgreSQL. Since queries will consume a variable amount of memory through parsing or preparation,
|
||||
an additional 10\% is saved as a precaution. This can be changed later as needed or desired for future optimizations. Specific to the graph data, the statement is made that the frontier is allowed to consume half of the allocated memory,
|
||||
\subsection{Checkpointing}
|
||||
Rather than only a static implementation of storing to the database on disk at a set interval or a set size, the goal was to also allow for dynamically storing to the database only when necessary. This would allow for proper utilization of systems with greater memory, and would reduce fine-tuning of a maximum size variable before database writes on different systems. Since there is an associated cost with preparing
|
||||
the writes to disk, the communication cost across nodes, the writing to disk itself, and a cost for retrieving items from disk, it may be desirable to store as much in memory for as long as possible and only checkpoint when necessary. When
|
||||
running RAGE, a new argument can be passed \textit{(-a $<$double$>$)} to specify the amount of memory the tool should use before writing to disk. This argument is a value between 0 and 0.99 to specify a percentage. Alternatively, an integer greater than or equal to 1 can be passed, which allows for a discrete number of states to be held in memory before checkpointing.
|
||||
If the value passed is between 0 and 1, it is immediately reduced by 10\%. For instance, if 0.6 is passed, it is immediately reduced to 0.5. This acts as a buffer for PostgreSQL. Since queries will consume a variable amount of memory through parsing or preparation,
|
||||
an additional 10\% is saved as a precaution. This can be changed as needed or desired for future optimizations. Specific to the graph data, the statement is made that the frontier is allowed to consume half of the allocated memory,
|
||||
and that the graph instance is allowed to consume the other half.
|
||||
|
||||
To decide when to store to the database instead of memory, two separate checks are made. The first check is for the frontier. If the size of the frontier consumes equal to or more than the allowed allocated memory, then all new states
|
||||
To decide when to checkpoint due to memory capacity, two separate checks are made. The first check is for the frontier. If the size of the frontier consumes equal to or more than the allowed allocated memory, then all new states
|
||||
are stored into a new table in the database called “unexplored states”. Each new state from this point forward is stored in the table, regardless of if room is freed in the frontier. This is to ensure proper ordering of the FIFO queue.
|
||||
The only time new states are stored directly into the frontier is when the unexplored states table is empty. Once the frontier has been completely emptied, new states are then pulled from the database into the frontier. To pull from
|
||||
the database, the parent loop for the generator process has been altered. Instead of a while loop for when the frontier is not empty, it has been adjusted to when the frontier is not empty or the unexplored states table is not empty. Due
|
||||
@ -94,35 +108,25 @@ performance benefits of memory operations, since graph computation relies less o
|
||||
For the graph instance, a check in the critical section determines if the size of the graph instance consumes more than its allocated share of the memory. If it does, the edges, network states, and network state items are written to the database,
|
||||
and are then removed from memory.
|
||||
|
||||
However, a new issue arose with database storage. The original design was to save staging, preparation, and communication cost by writing all the data in one query (as in, writing all of the network states in one query, all the network
|
||||
The original design was to save staging, preparation, and communication cost by writing all the data in one query (writing all of the network states in one query, all the network
|
||||
state items in one query, and all the edges in one query). While this was best option in terms of performance, it was also not feasible when the amount of data to store was large in relation to system memory. Building the SQL queries themselves quickly began depleting the already constrained memory with large storage
|
||||
requests. As a result, the storage process would consume too much memory and crash the generator tool. To combat this, all queries had to be broken up into multiple queries. As previously mentioned, an extra 10\% buffer was saved
|
||||
requests. As a result, the storage process would consume too much memory and invoke the Out-of-Memory Killer. To combat this, all queries had to be broken up into multiple queries. As previously mentioned, an extra 10\% buffer was saved
|
||||
for the storage process. SQL query strings are now built until they consume the 10\% buffer, where they are then processed by PostgreSQL, cleared, and the query building process resumes.
|
||||
|
||||
\subsection{Portability}
|
||||
The intermediate database storage is greatly advantageous in increasing the portability of RAGE across various systems, while still allowing for performance benefits. By allowing for a user-defined argument, users can safely assign
|
||||
a value that allows for other processes and for the host OS to continue their workloads. While the ``total memory" component currently utilizes the Linux \textit{sysconf()} function, this is not rigid and is easily adjustable. When
|
||||
working on an HPC cluster, using this function could lead to difficulties since multiple users may be working on the same nodes, which prevents RAGE from fully using all system memory. This could be prevented
|
||||
\subsubsection{Portability}
|
||||
The checkpointing process is greatly advantageous in increasing the portability of RAGE across various systems, while still allowing for performance benefits. By allowing for a user-defined argument, users can safely assign
|
||||
a value that allows for other processes and for the host OS to continue their workloads. While the ``total memory" component currently utilizes the Linux \textit{sysconf()} function, additional functionality can be built for alternative operating systems.
|
||||
When working on an HPC cluster, using this function could lead to difficulties since multiple users may be working on the same nodes, which prevents RAGE from fully using all system memory. This could be prevented
|
||||
by using a job scheduler argument such as Slurm's ``--exclusive" option, but this may not be desirable. Instead, a user could pass in the amount of total memory to use (and can be reused from a job scheduler's memory allocation
|
||||
request option), and the intermediate database storage process would function in the same fashion.
|
||||
request option), and the checkpointing process would function in the same fashion. Since PostgreSQL is used for the checkpointing, no file system dependencies are necessary for the cluster.
|
||||
|
||||
|
||||
\subsection{Restarting}
|
||||
|
||||
|
||||
|
||||
\subsection{Implementation Approach}
|
||||
|
||||
SCR: Adam Moody, Greg Bronevetsky, Kathryn Mohror, Bronis R. de Supinski, Design, Modeling, and Evaluation of a Scalable Multi-level Checkpointing System, LLNL-CONF-427742, Supercomputing 2010, New Orleans, LA, November 2010.
|
||||
|
||||
\subsection{Implementation Challenges}
|
||||
|
||||
\section{Results}
|
||||
|
||||
\section{Conclusion}
|
||||
|
||||
\section*{Acknowledgment}
|
||||
|
||||
\section*{References}
|
||||
\section{Conclusions and Future Work}
|
||||
|
||||
%\bibliographyp
|
||||
\bibliography{Bibliography}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user