-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
816 lines (549 loc) · 149 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Hexo</title>
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
<meta property="og:type" content="website">
<meta property="og:title" content="Hexo">
<meta property="og:url" content="https://worstkid92.github.io/papers.github.io/index.html">
<meta property="og:site_name" content="Hexo">
<meta property="og:locale" content="en_US">
<meta property="article:author" content="John Doe">
<meta name="twitter:card" content="summary">
<link rel="alternate" href="/papers.github.io/atom.xml" title="Hexo" type="application/atom+xml">
<link rel="shortcut icon" href="/papers.github.io/favicon.png">
<link rel="stylesheet" href="/papers.github.io/css/style.css">
<link rel="stylesheet" href="/papers.github.io/fancybox/jquery.fancybox.min.css">
<meta name="generator" content="Hexo 7.0.0"></head>
<body>
<div id="container">
<div id="wrap">
<header id="header">
<div id="banner"></div>
<div id="header-outer" class="outer">
<div id="header-title" class="inner">
<h1 id="logo-wrap">
<a href="/papers.github.io/" id="logo">Hexo</a>
</h1>
</div>
<div id="header-inner" class="inner">
<nav id="main-nav">
<a id="main-nav-toggle" class="nav-icon"><span class="fa fa-bars"></span></a>
<a class="main-nav-link" href="/papers.github.io/">Home</a>
<a class="main-nav-link" href="/papers.github.io/archives">Archives</a>
</nav>
<nav id="sub-nav">
<a class="nav-icon" href="/papers.github.io/atom.xml" title="RSS Feed"><span class="fa fa-rss"></span></a>
<a class="nav-icon nav-search-btn" title="Search"><span class="fa fa-search"></span></a>
</nav>
<div id="search-form-wrap">
<form action="//google.com/search" method="get" accept-charset="UTF-8" class="search-form"><input type="search" name="q" class="search-form-input" placeholder="Search"><button type="submit" class="search-form-submit"></button><input type="hidden" name="sitesearch" value="https://worstkid92.github.io/papers.github.io"></form>
</div>
</div>
</div>
</header>
<div class="outer">
<section id="main">
<article id="post-Deep-Learning-Focus" class="h-entry article article-type-post" itemprop="blogPost" itemscope itemtype="https://schema.org/BlogPosting">
<div class="article-meta">
<a href="/papers.github.io/2024/02/07/Deep-Learning-Focus/" class="article-date">
<time class="dt-published" datetime="2024-02-07T07:37:20.000Z" itemprop="datePublished">2024-02-07</time>
</a>
</div>
<div class="article-inner">
<header class="article-header">
<h1 itemprop="name">
<a class="p-name article-title" href="/papers.github.io/2024/02/07/Deep-Learning-Focus/">Deep Learning Focus</a>
</h1>
</header>
<div class="e-content article-entry" itemprop="articleBody">
<h1 id="quoted-url"><a href="#quoted-url" class="headerlink" title="quoted, url:"></a>quoted, url:</h1><p><a target="_blank" rel="noopener" href="https://cameronrwolfe.substack.com/p/language-model-training-and-inference">https://cameronrwolfe.substack.com/p/language-model-training-and-inference</a><br><a target="_blank" rel="noopener" href="https://cameronrwolfe.substack.com/p/graph-based-prompting-and-reasoning#%C2%A7the-transformer-from-top-to-bottom">https://cameronrwolfe.substack.com/p/graph-based-prompting-and-reasoning#%C2%A7the-transformer-from-top-to-bottom</a><br><a target="_blank" rel="noopener" href="https://cameronrwolfe.substack.com/p/chain-of-thought-prompting-for-llms">https://cameronrwolfe.substack.com/p/chain-of-thought-prompting-for-llms</a><br><a target="_blank" rel="noopener" href="https://cameronrwolfe.substack.com/p/tree-of-thoughts-prompting">https://cameronrwolfe.substack.com/p/tree-of-thoughts-prompting</a></p>
<h1 id="Language-Model-Scaling-Laws"><a href="#Language-Model-Scaling-Laws" class="headerlink" title="Language Model Scaling Laws"></a>Language Model Scaling Laws</h1><p>url:<a target="_blank" rel="noopener" href="https://cameronrwolfe.substack.com/p/language-model-scaling-laws-and-gpt#%C2%A7language-models-are-few-shot-learners">https://cameronrwolfe.substack.com/p/language-model-scaling-laws-and-gpt#%C2%A7language-models-are-few-shot-learners</a><br><a target="_blank" rel="noopener" href="https://cameronrwolfe.substack.com/p/language-models-gpt-and-gpt-2#%C2%A7prerequisites-for-gpt">https://cameronrwolfe.substack.com/p/language-models-gpt-and-gpt-2#%C2%A7prerequisites-for-gpt</a><br><img src="https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F89687ad1-ab5d-4c72-840c-343d7fa26ab2_1854x1030.png" alt="pre-trainning"><br>GPT 模型是利用语言建模目标，通过未标注文本数据的语料库/数据集进行预训练的。简单地说，这意味着我们通过以下方式来训练模型：(i) 从数据集中抽取一些文本；(ii) 训练模型预测下一个单词；见上图。这种预训练过程是一种自我监督学习，因为只需查看数据集中的下一个单词，就能确定正确的 “下一个 “单词。</p>
<h2 id="数学中的语言建模。"><a href="#数学中的语言建模。" class="headerlink" title="数学中的语言建模。"></a>数学中的语言建模。</h2><p>要理解语言建模，我们只需掌握上述基本概念。不过，为了使这一点更加严谨，我们可以注意到，我们的语料库只是一组标记。我们可以将标记视为数据集中的单个单词，但这并不完全正确。实际上，标记可能是子词，甚至是字符；<br>有一组tokens<br><img src="https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F45501723-a132-40e7-8cb8-5050b2b265fb_1328x378.png" alt="语料库"><br>![modeling loss](<a target="_blank" rel="noopener" href="https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws">https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws</a>.<br>com%2Fpublic%2Fimages%2F3430b67c-2d19-4840-9207-09e68a25d03a_1318x444.png)</p>
<h3 id="why-use-log"><a href="#why-use-log" class="headerlink" title="why use log"></a>why use log</h3><p><a target="_blank" rel="noopener" href="https://chrispiech.github.io/probabilityForComputerScientists/en/part1/log_probabilities/">https://chrispiech.github.io/probabilityForComputerScientists/en/part1/log_probabilities/</a><br><a target="_blank" rel="noopener" href="https://www.hackerearth.com/practice/machine-learning/prerequisites-of-machine-learning/bayes-rules-conditional-probability-chain-rule/tutorial/">https://www.hackerearth.com/practice/machine-learning/prerequisites-of-machine-learning/bayes-rules-conditional-probability-chain-rule/tutorial/</a><br>利用语言建模损失（它只是表征我们的模型准确预测序列中下一个标记的能力！），我们可以按照下面的步骤预训练模型参数 θ，从而使损失最小：<br>1.预训练语料库中的样本文本<br>2.用我们的模型预测下一个标记<br>3.使用随机梯度下降（SGD）或其他优化器，提高下一个标记的正确概率<br>通过多次重复这种（自我监督）训练过程，我们的模型最终会成为真正的语言建模高手（即预测序列中的下一个标记）。</p>
<h3 id="什么是语言模型？"><a href="#什么是语言模型？" class="headerlink" title="什么是语言模型？"></a>什么是语言模型？</h3><p>使用这种自监督语言建模目标预先训练的模型通常被称为语言模型（LM）。LM 随着规模的扩大（即层数和参数的增加等）而变得更加有效。因此，我们经常会看到这些模型的大型版本（如 GPT-3），它们被称为大型语言模型 (LLM)。</p>
<h3 id="为什么-LMs-有用？"><a href="#为什么-LMs-有用？" class="headerlink" title="为什么 LMs 有用？"></a>为什么 LMs 有用？</h3><p>LM 可以通过迭代预测最有可能出现的下一个标记来生成连贯的文本，这使得从文本自动完成到聊天机器人等一系列应用成为可能。不过，除了生成能力之外，NLP 领域的前期工作已经表明，LM 预训练对各种任务都有极大的帮助；例如，预训练的词嵌入在下游任务中非常有用，LM预训练可以提高 LSTM 的性能。<br>在这些方法之外，GPT 模型探索了使用转换器进行语言模型预训练的方法。与顺序模型（如 LSTM）相比，变换器（i）具有令人难以置信的表现力（即高表示能力、多参数等），（ii）更适合现代 GPU 的并行计算能力，允许使用更大的模型和更多的数据进行 LM 预训练。这种可扩展性使 LLM 的探索成为可能，而 LLM 已经彻底改变了 NLP 的应用。<br>(tranformers:<a target="_blank" rel="noopener" href="https://cameronrwolfe.substack.com/p/vision-transformers#%C2%A7background">https://cameronrwolfe.substack.com/p/vision-transformers#%C2%A7background</a>)<br><img src="https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F57f3c98e-39d1-4eda-9a53-309210d42f49_662x968.png" alt="transformer"></p>
<h2 id="纯解码transformer"><a href="#纯解码transformer" class="headerlink" title="纯解码transformer"></a>纯解码transformer</h2><p>GPT 和 GPT-2 都使用纯解码器变压器架构。上面博客链接里有。<br><img src="https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F91a045da-57be-437d-962c-529ee5bc93fb_1234x828.png" alt="decoder-only transformers"><br>decoder-only transformers移除了以下组件：<br>整个编码器模块<br>解码器中的所有编码器-解码器自注意模块<br>移除这些组件后，解码器的每一层都由一个屏蔽自注意层和一个前馈神经网络组成。将几个这样的层堆叠在一起，就形成了一个深度解码器专用变压器架构，例如用于 GPT 或 GPT-2 的架构；</p>
<h3 id="为什么使用解码器？"><a href="#为什么使用解码器？" class="headerlink" title="为什么使用解码器？"></a>为什么使用解码器？</h3><p>选择使用解码器架构（而不是编码器）来处理 LM，因为解码器中的屏蔽的self-attention layers确保了模型在制作标记表示时不能在序列中向前看。与此相反，self-attention（在编码器中使用）允许根据序列中的所有其他标记来调整每个标记的表示。因为在预测下一个标记时，我们不应该向前看句子。使用屏蔽的self-attention layers会产生一种自回归结构（即模型在时间 t 的输出被用作时间 t+1 的输入），它可以持续预测序列中的下一个标记。</p>
<h1 id="chain-of-thought"><a href="#chain-of-thought" class="headerlink" title="chain of thought"></a>chain of thought</h1><p><img src="https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F2be86a82-3d94-444c-90a2-9428ff629b2f_1994x1404.png" alt="pic.1 chain of thought"></p>
<h1 id="transformer"><a href="#transformer" class="headerlink" title="transformer"></a>transformer</h1><p><img src="https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F553be3b4-3c80-435d-88c5-c7079bff9cbb_1940x1090.png" alt="pic.1 总览"></p>
</div>
<footer class="article-footer">
<a data-url="https://worstkid92.github.io/papers.github.io/2024/02/07/Deep-Learning-Focus/" data-id="clsbhg7bb0002j4va2bn4dxfq" data-title="Deep Learning Focus" class="article-share-link"><span class="fa fa-share">Share</span></a>
</footer>
</div>
</article>
<article id="post-Code-Generation-Using-Machine-Learning-A-Systematic-Review" class="h-entry article article-type-post" itemprop="blogPost" itemscope itemtype="https://schema.org/BlogPosting">
<div class="article-meta">
<a href="/papers.github.io/2024/01/30/Code-Generation-Using-Machine-Learning-A-Systematic-Review/" class="article-date">
<time class="dt-published" datetime="2024-01-30T10:26:16.000Z" itemprop="datePublished">2024-01-30</time>
</a>
</div>
<div class="article-inner">
<header class="article-header">
<h1 itemprop="name">
<a class="p-name article-title" href="/papers.github.io/2024/01/30/Code-Generation-Using-Machine-Learning-A-Systematic-Review/">Code Generation Using Machine Learning: A Systematic Review</a>
</h1>
</header>
<div class="e-content article-entry" itemprop="articleBody">
<p>url: <a target="_blank" rel="noopener" href="https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9849664">https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9849664</a></p>
</div>
<footer class="article-footer">
<a data-url="https://worstkid92.github.io/papers.github.io/2024/01/30/Code-Generation-Using-Machine-Learning-A-Systematic-Review/" data-id="clsbhg7ba0001j4vab6va0c67" data-title="Code Generation Using Machine Learning: A Systematic Review" class="article-share-link"><span class="fa fa-share">Share</span></a>
</footer>
</div>
</article>
<article id="post-GPU-Acceleration-in-Unikernels-Using-Cricket-GPU-Virtualization" class="h-entry article article-type-post" itemprop="blogPost" itemscope itemtype="https://schema.org/BlogPosting">
<div class="article-meta">
<a href="/papers.github.io/2024/01/08/GPU-Acceleration-in-Unikernels-Using-Cricket-GPU-Virtualization/" class="article-date">
<time class="dt-published" datetime="2024-01-08T01:05:10.000Z" itemprop="datePublished">2024-01-08</time>
</a>
</div>
<div class="article-inner">
<header class="article-header">
<h1 itemprop="name">
<a class="p-name article-title" href="/papers.github.io/2024/01/08/GPU-Acceleration-in-Unikernels-Using-Cricket-GPU-Virtualization/">GPU Acceleration in Unikernels Using Cricket GPU Virtualization</a>
</h1>
</header>
<div class="e-content article-entry" itemprop="articleBody">
</div>
<footer class="article-footer">
<a data-url="https://worstkid92.github.io/papers.github.io/2024/01/08/GPU-Acceleration-in-Unikernels-Using-Cricket-GPU-Virtualization/" data-id="clsbhg7b70000j4va7ehg8k50" data-title="GPU Acceleration in Unikernels Using Cricket GPU Virtualization" class="article-share-link"><span class="fa fa-share">Share</span></a>
</footer>
</div>
</article>
<article id="post-Loupe-Driving-the-Development-of-OS-Compatibility-Layers" class="h-entry article article-type-post" itemprop="blogPost" itemscope itemtype="https://schema.org/BlogPosting">
<div class="article-meta">
<a href="/papers.github.io/2024/01/08/Loupe-Driving-the-Development-of-OS-Compatibility-Layers/" class="article-date">
<time class="dt-published" datetime="2024-01-08T00:57:54.000Z" itemprop="datePublished">2024-01-08</time>
</a>
</div>
<div class="article-inner">
<header class="article-header">
<h1 itemprop="name">
<a class="p-name article-title" href="/papers.github.io/2024/01/08/Loupe-Driving-the-Development-of-OS-Compatibility-Layers/">Loupe: Driving the Development of OS Compatibility Layers</a>
</h1>
</header>
<div class="e-content article-entry" itemprop="articleBody">
<p>REPO:<a target="_blank" rel="noopener" href="https://github.com/unikraft/loupe">https://github.com/unikraft/loupe</a> <a target="_blank" rel="noopener" href="https://github.com/unikraft/loupedb">https://github.com/unikraft/loupedb</a></p>
</div>
<footer class="article-footer">
<a data-url="https://worstkid92.github.io/papers.github.io/2024/01/08/Loupe-Driving-the-Development-of-OS-Compatibility-Layers/" data-id="clsbhg7bc0003j4vahi231vpg" data-title="Loupe: Driving the Development of OS Compatibility Layers" class="article-share-link"><span class="fa fa-share">Share</span></a>
</footer>
</div>
</article>
<article id="post-reading-list" class="h-entry article article-type-post" itemprop="blogPost" itemscope itemtype="https://schema.org/BlogPosting">
<div class="article-meta">
<a href="/papers.github.io/2023/12/21/reading-list/" class="article-date">
<time class="dt-published" datetime="2023-12-21T02:57:47.000Z" itemprop="datePublished">2023-12-21</time>
</a>
</div>
<div class="article-inner">
<header class="article-header">
<h1 itemprop="name">
<a class="p-name article-title" href="/papers.github.io/2023/12/21/reading-list/">reading list</a>
</h1>
</header>
<div class="e-content article-entry" itemprop="articleBody">
<h1 id="Unikernel-Papers"><a href="#Unikernel-Papers" class="headerlink" title="Unikernel Papers"></a>Unikernel Papers</h1><p>This repository is a list of all systems papers regarding the topic of unikernels. Feel free to contribute with a pull request!</p>
<h2 id="Papers"><a href="#Papers" class="headerlink" title="Papers"></a>Papers</h2><h3 id="2024"><a href="#2024" class="headerlink" title="2024"></a>2024</h3><ul>
<li><a target="_blank" rel="noopener" href="https://arxiv.org/abs/2309.15996"><strong>Loupe: Driving the Development of OS Compatibility Layers</strong></a>, <em>ASPLOS’24</em></li>
</ul>
<h3 id="2023"><a href="#2023" class="headerlink" title="2023"></a>2023</h3><ul>
<li><a target="_blank" rel="noopener" href="https://doi.org/10.1145/3624062.3624236"><strong>GPU Acceleration in Unikernels Using Cricket GPU Virtualization</strong></a>, <em>SC-W 2023</em></li>
<li><a target="_blank" rel="noopener" href="http://nets.cs.pub.ro/~costin/files/nephele.pdf"><strong>Nephele: Extending Virtualization Environments for Cloning Unikernel-based VMs</strong></a>, <em>EuroSys’23</em></li>
<li><a target="_blank" rel="noopener" href="https://dl.acm.org/doi/10.1145/3552326.3587458"><strong>Unikernel Linux (UKL)</strong></a>, <em>EuroSys’23</em> (UKL)</li>
<li><a target="_blank" rel="noopener" href="https://arxiv.org/abs/2309.11332"><strong>Software Compartmentalization Trade-Offs with Hardware Capabilities</strong></a>, <em>PLOS’23</em> (FlexOS)</li>
<li><a target="_blank" rel="noopener" href="https://github.com/olivierpierre/unikernel-papers/files/12648020/andrej-velichkovski-report.pdf"><strong>Assessing Scalability and Performance Isolation of Lightweight Virtualization Systems</strong></a> (BSc project report)</li>
<li><a target="_blank" rel="noopener" href="https://github.com/olivierpierre/unikernel-papers/files/12648143/nathan-jones-report.pdf"><strong>Exploring Unikernels for Serverless Computing</strong></a> (BSc project report)</li>
</ul>
<h3 id="2022"><a href="#2022" class="headerlink" title="2022"></a>2022</h3><ul>
<li><a target="_blank" rel="noopener" href="https://dl.acm.org/doi/10.1145/3492321.3519578"><strong>KASLR in the age of MicroVMs</strong></a>, <em>EuroSys’22</em></li>
<li><a target="_blank" rel="noopener" href="https://ssrg.ece.vt.edu/papers/eurosys22.pdf"><strong>Kite: Lightweight Critical Service Domains</strong></a>, <em>EuroSys’22</em></li>
<li><a target="_blank" rel="noopener" href="https://arxiv.org/pdf/2112.06566.pdf"><strong>FlexOS: Towards Flexible OS Isolation</strong></a>, <em>ASPLOS’22</em> (FlexOS)</li>
<li><a target="_blank" rel="noopener" href="https://drive.google.com/file/u/0/d/1aC3zGtwX7D8Nw897DiqKe6v3I3Gxx7oh/view"><strong>Analyzing Unikernel Support for HPC: Experimental Study of OpenMP</strong></a>, <em>ISC High Performance’22 International Workshops</em></li>
</ul>
<h3 id="2021"><a href="#2021" class="headerlink" title="2021"></a>2021</h3><ul>
<li><a target="_blank" rel="noopener" href="https://dl.acm.org/doi/abs/10.1145/3447786.3456248"><strong>Unikraft: fast, specialized unikernels the easy way</strong></a> <em>EuroSys’21</em> (Unikraft)</li>
<li><a target="_blank" rel="noopener" href="https://eprints.lancs.ac.uk/id/eprint/157674/2/apsys21_final10.pdf"><strong>Wayfinder: towards automatically deriving optimal OS configurations</strong></a> <em>APSys’21</em> (Unikraft)</li>
<li><a target="_blank" rel="noopener" href="https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s05-lefeuvre.pdf"><strong>FlexOS: Making OS Isolation Flexible</strong></a>, <em>HotOS’21</em></li>
<li><a target="_blank" rel="noopener" href="https://dl.acm.org/doi/10.1145/3436512"><strong>KylinX: Simplified Virtualization Architecture for Specialized Virtual Appliances with Strong Isolation</strong></a>, <em>ACM TOCS 2021</em></li>
<li><a target="_blank" rel="noopener" href="https://lsds.doc.ic.ac.uk/sites/default/files/sartakov%4021cubicleos.pdf"><strong>CubicleOS: A Library OS with Software Componentisation for Practical Isolation</strong></a> <em>ASPLOS’21</em></li>
<li><a target="_blank" rel="noopener" href="https://github.com/ssrg-vt/hermitux/wiki/files/christopher-densham-project-report.pdf"><strong>Binary-Compatibility with Linux Application for a Unikernel Written in Rust (1)</strong></a> (BSc project report)</li>
<li><a target="_blank" rel="noopener" href="https://github.com/ssrg-vt/hermitux/wiki/files/laurent-pool-project-report.pdf"><strong>Binary-Compatibility with Linux Application for a Unikernel Written in Rust (2)</strong></a> (BSc project report)</li>
<li><a target="_blank" rel="noopener" href="https://github.com/ssrg-vt/hermitux/wiki/files/oliver-dunk-project-report.pdf"><strong>Applying OS Fuzzing Techniques to Unikernels,</strong></a> (BSc project report)</li>
<li><a target="_blank" rel="noopener" href="https://github.com/ssrg-vt/hermitux/wiki/files/jacquot-pierre-graduation-project.pdf"><strong>Evaluating unikernels for HPC applications</strong></a> (MS thesis)</li>
</ul>
<h3 id="2020"><a href="#2020" class="headerlink" title="2020"></a>2020</h3><ul>
<li><a target="_blank" rel="noopener" href="https://pub.nderjung.net/papers/emsoft20.pdf"><strong>Towards Highly Specialized, POSIX-compliant Software Stacks with Unikraft: Work-in-Progress</strong></a> <em>EMSOFT’20</em> (Unikraft)</li>
<li><a target="_blank" rel="noopener" href="https://www.ssrg.ece.vt.edu/papers/vee20-mpk.pdf"><strong>Intra-Unikernel Isolation with Intel Memory Protection Keys</strong></a>, <em>VEE’20</em> (HermitCore)</li>
<li><a target="_blank" rel="noopener" href="https://hckuo.github.io/pdfs/lupine.pdf"><strong>A Linux in Unikernel Clothing</strong></a> Eurosys’20 (Lupine)</li>
<li><a target="_blank" rel="noopener" href="https://ieeexplore.ieee.org/document/9138883"><strong>A security perspective on Unikernels</strong></a>, <em>IEEE Cyber Security 2020</em></li>
<li><a target="_blank" rel="noopener" href="https://cybersecurity.springeropen.com/articles/10.1186/s42400-020-00051-9"><strong>Iso-UniK: lightweight multi-process unikernel through memory protection keys</strong></a> <em>Springer Cybersecurity 2020</em></li>
<li><a target="_blank" rel="noopener" href="https://dl.acm.org/doi/abs/10.1145/3342195.3392698"><strong>SEUSS: skip redundant paths to make serverless fast</strong></a> Eurosys’20</li>
<li><a target="_blank" rel="noopener" href="https://dl.acm.org/doi/pdf/10.1145/3378679.3394537"><strong>The Serverkernel Operating System</strong></a> <em>EdgeSys’20</em></li>
<li><a target="_blank" rel="noopener" href="https://www.ssrg.ece.vt.edu/papers/spma20.pdf"><strong>The Case for Intra-Unikernel Isolation</strong></a>, <em>SPMA’20</em></li>
<li><a target="_blank" rel="noopener" href="https://link.springer.com/chapter/10.1007/978-3-030-59851-8_22"><strong>RustyHermit: A Scalable, Rust-Based Virtual Execution Environment</strong></a>, <em>ISC High Performance 2020</em> (RustyHermit)</li>
</ul>
<h3 id="2019"><a href="#2019" class="headerlink" title="2019"></a>2019</h3><ul>
<li><a target="_blank" rel="noopener" href="https://www.ssrg.ece.vt.edu/papers/vee2019.pdf"><strong>A Binary-Compatible Unikernel</strong></a>, <em>VEE’19</em> (HermiTux)</li>
<li><a target="_blank" rel="noopener" href="https://dl.acm.org/doi/10.1145/3317550.3321445"><strong>Unikernels: The Next Stage of Linux’s Dominance</strong></a>, <em>HotOS’19</em></li>
<li><a target="_blank" rel="noopener" href="https://dl.acm.org/doi/10.1145/3365137.3365395"><strong>Exploring Rust for Unikernel Development</strong></a>, <em>PLOS’19</em> (RustyHermit)</li>
</ul>
<h3 id="2018"><a href="#2018" class="headerlink" title="2018"></a>2018</h3><ul>
<li><a target="_blank" rel="noopener" href="https://www.sciencedirect.com/science/article/pii/S0167739X17329734"><strong>Android Unikernel: Gearing mobile code offloading towards edge computing</strong></a>, <em>FGCS 2018</em></li>
<li><a target="_blank" rel="noopener" href="http://home.in.tum.de/~ding/files/netmag-pre-camera.pdf"><strong>Consolidate IoT Edge Computing with Lightweight Virtualization</strong></a> <em>IEEE Network 2018</em></li>
<li><a target="_blank" rel="noopener" href="https://ieeexplore.ieee.org/abstract/document/8360317/"><strong>Uniguard: Protecting Unikernel using Intel SGX</strong></a>, <em>IEEE IC2E 2018</em></li>
<li><a target="_blank" rel="noopener" href="https://www.researchgate.net/profile/Lefteris_Mamatas/publication/325206124_Elastic_Content_Distribution_Based_on_Unikernels_and_Change-Point_Analysis/links/5afdcae9458515e9a535d2f6/Elastic-Content-Distribution-Based-on-Unikernels-and-Change-Point-Analysis.pdf"><strong>Elastic Content Distribution Based on Unikernels and Change-Point Analysis</strong></a> <em>Europeean Wireless 2018</em></li>
<li><a target="_blank" rel="noopener" href="https://arxiv.org/pdf/1806.00039.pdf"><strong>Blip: JIT and Footloose On The Edge</strong></a>, <em>arXiv 2018</em></li>
<li><a target="_blank" rel="noopener" href="https://hal.inria.fr/hal-01798793/document"><strong>Unikernel-based Approach for Software-Defined Security in Cloud Infrastructures</strong></a> <em>IEEE NOMS 2018</em></li>
<li><a target="_blank" rel="noopener" href="https://www.usenix.org/system/files/conference/atc18/atc18-zhang-yiming.pdf"><strong>KylinX: A Dynamic Library Operating System for Simplified and Efficient Cloud Virtualization</strong></a> <em>ATC’18</em></li>
<li><a target="_blank" rel="noopener" href="https://dl.acm.org/doi/10.1145/3267809.3267845"><strong>Unikernels as Processes</strong></a>, <em>SOCC’18</em></li>
<li><a target="_blank" rel="noopener" href="https://dl.acm.org/doi/abs/10.1145/3343737.3343750"><strong>USETL: Unikernels for Serverless Extract Transform and Load Why should you settle for less?</strong></a>, <em>APSys’18</em></li>
<li><a target="_blank" rel="noopener" href="https://ieeexplore.ieee.org/abstract/document/8406931"><strong>An architecture for interspatial communication</strong></a>, <em>INFOCOM’18</em></li>
<li><a target="_blank" rel="noopener" href="https://www.researchgate.net/profile/Bob_Duncan/publication/323295473_Using_Unikernels_to_Address_the_Cloud_Forensic_Problem_and_help_Achieve_EU_GDPR_Compliance/links/5a8c97cca6fdcc786eafd9dc/Using-Unikernels-to-Address-the-Cloud-Forensic-Problem-and-help-Achieve-EU-GDPR-Compliance.pdf"><strong>Using Unikernels to Address the Cloud Forensic Problem and help Achieve EU GDPR Compliance</strong></a>, <em>Cloud Computing Conference 2018</em></li>
<li><a target="_blank" rel="noopener" href="https://dominoweb.draco.res.ibm.com/reports/H-0330.pdf"><strong>A Comparison of Virtualization Technologies for Use in Cloud Data Centers</strong></a> (technical report)</li>
<li><a target="_blank" rel="noopener" href="https://github.com/ssrg-vt/hermitux/blob/master/doc/daniel-chiba-ms-thesis.pdf"><strong>Optimizing Boot Times and Enhancing Binary Compatibility for Unikernels</strong></a> (MS thesis)</li>
</ul>
<h3 id="2017"><a href="#2017" class="headerlink" title="2017"></a>2017</h3><ul>
<li><a target="_blank" rel="noopener" href="http://sysml.neclab.eu/projects/lightvm/lightvm.pdf"><strong>My VM is Lighter (and Safer) than your Container</strong></a>, <em>SOSP17</em></li>
<li><a target="_blank" rel="noopener" href="http://flosch.eu/papers/2017-vee-minicache.pdf"><strong>Unikernels Everywhere: The Case for Elastic CDNs</strong></a>, <em>VEE17</em></li>
<li><a target="_blank" rel="noopener" href="http://dl.acm.org/citation.cfm?id=3132009"><strong>Enabling Fine-Grained Edge Offloading for IoT</strong></a>, <em>SIGCOMM17</em> (Poster)</li>
<li><a target="_blank" rel="noopener" href="http://dl.acm.org/citation.cfm?id=3094412"><strong>FADES: Fine-Grained Edge Offloading with Unikernels</strong></a>, <em>HotConNet17</em></li>
<li><a target="_blank" rel="noopener" href="https://s3.amazonaws.com/academia.edu.documents/51935992/cloud_computing_2017_full.pdf?AWSAccessKeyId=AKIAIWOWYYGZ2Y53UL3A&Expires=1506032443&Signature=rG0TWnFneEUY7Ik/mPCbvMBiMvs=&response-content-disposition=inline;%20filename=CLOUD_COMPUTING_2017_Athens_Greece_CLOUD.pdf#page=21"><strong>Making the Case for Highly Efficient Multicore Enabled Unikernels With IncludeOS</strong></a>, <em>CLOUD COMPUTING 17</em></li>
<li><a target="_blank" rel="noopener" href="https://link.springer.com/content/pdf/10.1007%2F978-3-319-67262-5_3.pdf"><strong>A Performance Survey of Lightweight Virtualization Techniques</strong></a>, <em>Springer LNCS17</em></li>
<li><a target="_blank" rel="noopener" href="https://www.researchgate.net/profile/Ioannis_Psaras/publication/319925427_NFaaS_named_function_as_a_service/links/59c4aad0a6fdccc7190e7806/NFaaS-named-function-as-a-service.pdf"><strong>NFaaS: Named Function as a Service</strong></a>, <em>ICN17</em></li>
<li><a target="_blank" rel="noopener" href="http://flosch.eu/papers/2017-sigcomm-uniprof.pdf"><strong>uniprof: A Unikernel Stack Profiler</strong></a>, <em>SIGCOMM17</em> (poster)</li>
<li><a target="_blank" rel="noopener" href="https://dl.acm.org/citation.cfm?id=3133855"><strong>The serverless trilemma: function composition for serverless computing</strong></a> <em>Onward! 2017</em></li>
<li><a target="_blank" rel="noopener" href="http://www.cs.binghamton.edu/~zhangy/paper/EdgeCourier-SEC17.pdf"><strong>EdgeCourier: An Edge-hosted Personal Service for Low-bandwidth Document Synchronization in Mobile Cloud Storage Services</strong></a> <em>SEC’17</em></li>
<li><a target="_blank" rel="noopener" href="https://www.researchgate.net/profile/Evangelos_Markakis/publication/321143166_Computing_Caching_and_Communication_at_the_Edge_The_Cornerstone_for_Building_a_Versatile_5G_Ecosystem/links/5a1bea794585155c26ae0dd0/Computing-Caching-and-Communication-at-the-Edge-The-Cornerstone-for-Building-a-Versatile-5G-Ecosystem.pdf"><strong>Communication, Compute and Caching (3C) at the edge: The cornerstone for building a versatile 5G ecosystem</strong></a> <em>IEEE Communications Magazine 2017</em></li>
<li><a target="_blank" rel="noopener" href="https://www.atiner.gr/papers/COM2017-2327.pdf"><strong>An Architecture for Reliable Industry 4.0 Appliances</strong></a>, <em>ATINER’s Conference Paper Series 2-17</em></li>
<li><a target="_blank" rel="noopener" href="https://orum.in/sosp2017-mkanatsu-abstract.pdf"><strong>Running Multi-Process Applications on Unikernel-based VMs</strong></a> <em>SOSP17 Poster</em> (<a target="_blank" rel="noopener" href="https://orum.in/sosp2017-mkanatsu-poster.pdf">Poster</a>)</li>
<li><a target="_blank" rel="noopener" href="http://aura.abdn.ac.uk/bitstream/handle/2164/8524/AAB02.pdf"><strong>Enhancing Cloud Security and Privacy: The Unikernel Solution</strong></a> <em>Cloud Computing 2017</em></li>
<li><a target="_blank" rel="noopener" href="https://ieeexplore.ieee.org/abstract/document/7923803/authors#authors"><strong>PHP2Uni: Building Unikernels Using Scripting Language Transpilation</strong></a>, <em>IC2E’17</em></li>
<li><a target="_blank" rel="noopener" href="https://link.springer.com/chapter/10.1007/978-3-319-54999-6_6"><strong>A Low Noise Unikernel for Extrem-Scale Systems</strong></a> <em>ARCS’17</em> (HermitCore)</li>
<li><a target="_blank" rel="noopener" href="https://www.duo.uio.no/bitstream/handle/10852/59234/final_complete_version_2017_08_01.pdf?sequence=1"><strong>A model for increasing the performance of an automated testing pipeline</strong></a> (MS thesis)</li>
<li><a target="_blank" rel="noopener" href="https://www.duo.uio.no/bitstream/handle/10852/59240/live-updating-unikernels.pdf?sequence=45"><strong>Live Updating in Unikernels</strong></a> (MS thesis)</li>
</ul>
<h3 id="2016"><a href="#2016" class="headerlink" title="2016"></a>2016</h3><ul>
<li><a target="_blank" rel="noopener" href="http://dl.acm.org/citation.cfm?id=2931093"><strong>HermitCore: A Unikernel for Extreme Scale Computing</strong></a>, <em>ROSS16</em></li>
<li><a target="_blank" rel="noopener" href="https://arxiv.org/pdf/1605.06285.pdf"><strong>On the Fly TCP Acceleration with Miniproxy</strong></a>, <em>HotMiddleBox16</em></li>
<li><a target="_blank" rel="noopener" href="http://aura.abdn.ac.uk/bitstream/handle/2164/7988/PID4488667.pdf"><strong>Enterprise IoT security and scalability: how unikernels can improve the status Quo</strong></a>, <em>UUC16</em></li>
<li><a target="_blank" rel="noopener" href="http://ieeexplore.ieee.org/document/7515699/#full-text-section"><strong>Time provisioning Evaluation of KVM, Docker and Unikernels in a Cloud Platform</strong></a> <em>CCGRID’16</em></li>
</ul>
<h3 id="2015"><a href="#2015" class="headerlink" title="2015"></a>2015</h3><ul>
<li><a target="_blank" rel="noopener" href="https://www.usenix.org/system/files/conference/nsdi15/nsdi15-paper-madhavapeddy.pdf"><strong>Jitsu: Just-In-Time Summoning of Unikernels</strong></a>, <em>NSDI 2015</em> (MirageOS)</li>
<li><a target="_blank" rel="noopener" href="https://folk.uio.no/paalee/publications/2015-cloudcom.pdf"><strong>IncludeOS: A minimal, resource efficient unikernel for cloud services</strong></a>, (CloudCom15)</li>
<li><a target="_blank" rel="noopener" href="https://www.usenix.org/system/files/conference/hotcloud15/hotcloud15-manco.pdf"><strong>The Case for the Superfluid Cloud</strong></a>, <em>HotCloud15</em></li>
</ul>
<h3 id="2014"><a href="#2014" class="headerlink" title="2014"></a>2014</h3><ul>
<li><a target="_blank" rel="noopener" href="http://queue.acm.org/detail.cfm?id=2566628"><strong>Unikernels: Rise of the Virtual Library Operating System</strong></a>, <em>ACM Queue 2014</em> (MirageOS)</li>
<li><a target="_blank" rel="noopener" href="https://www.usenix.org/system/files/login/articles/login_1410_03_kantee.pdf"><strong>Rump Kernels: No OS? No Problem!</strong></a>, <em>;login14</em> (Rump)</li>
<li><a target="_blank" rel="noopener" href="http://spin2013.cs.sunysb.edu/~porter/pubs/tsai14graphene.pdf"><strong>Cooperation and Security Isolation of Library OSes for Multi-Process Applications</strong></a> <em>EuroSys 2014</em> (Graphene)</li>
<li><a target="_blank" rel="noopener" href="https://www.usenix.org/system/files/conference/atc14/atc14-paper-kivity.pdf"><strong>OSv—Optimizing the Operating System for Virtual Machines</strong></a>, <em>ATC’14</em></li>
<li><a target="_blank" rel="noopener" href="https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-martins.pdf"><strong>ClickOS and the art of network function virtualization</strong></a> <em>NSDI’14</em></li>
</ul>
<h3 id="2013"><a href="#2013" class="headerlink" title="2013"></a>2013</h3><ul>
<li><a target="_blank" rel="noopener" href="http://anil.recoil.org/papers/2013-asplos-mirage.pdf"><strong>Unikernels: Library Operating Systems for the Cloud</strong></a>, <em>ASPLOS13</em> (MirageOS)</li>
</ul>
<h3 id="2011"><a href="#2011" class="headerlink" title="2011"></a>2011</h3><ul>
<li><a target="_blank" rel="noopener" href="https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/asplos2011-drawbridge.pdf"><strong>Rethinking the Library OS from the Top Down</strong></a>, <em>ASPLOS11</em> (Drawbridge)</li>
</ul>
<h2 id="Misc"><a href="#Misc" class="headerlink" title="Misc."></a>Misc.</h2><ul>
<li>Some general info about unikernels: this website, in particular have a look at the “Project” tab:<br><a target="_blank" rel="noopener" href="http://unikernel.org/">http://unikernel.org/</a></li>
<li>Not a paper, but interesting:<br><a target="_blank" rel="noopener" href="https://www.sigarch.org/leave-your-os-at-home-the-rise-of-library-operating-systems/">https://www.sigarch.org/leave-your-os-at-home-the-rise-of-library-operating-systems/</a></li>
<li>Profiling unikernels:<br><a target="_blank" rel="noopener" href="http://www.brendangregg.com/blog/2016-01-27/unikernel-profiling-from-dom0.html">http://www.brendangregg.com/blog/2016-01-27/unikernel-profiling-from-dom0.html</a><ul>
<li>There is also the X-ray profiler used in HermitCore: <a target="_blank" rel="noopener" href="https://github.com/RWTH-OS/HermitCore/tree/master/usr/xray">https://github.com/RWTH-OS/HermitCore/tree/master/usr/xray</a></li>
</ul>
</li>
</ul>
</div>
<footer class="article-footer">
<a data-url="https://worstkid92.github.io/papers.github.io/2023/12/21/reading-list/" data-id="clqk8x19m0001akvah1kzffuo" data-title="reading list" class="article-share-link"><span class="fa fa-share">Share</span></a>
</footer>
</div>
</article>
<article id="post-Towards-a-Machine-Learning-Assisted-Kernel-with-LAKE" class="h-entry article article-type-post" itemprop="blogPost" itemscope itemtype="https://schema.org/BlogPosting">
<div class="article-meta">
<a href="/papers.github.io/2023/12/20/Towards-a-Machine-Learning-Assisted-Kernel-with-LAKE/" class="article-date">
<time class="dt-published" datetime="2023-12-20T00:51:16.000Z" itemprop="datePublished">2023-12-20</time>
</a>
</div>
<div class="article-inner">
<header class="article-header">
<h1 itemprop="name">
<a class="p-name article-title" href="/papers.github.io/2023/12/20/Towards-a-Machine-Learning-Assisted-Kernel-with-LAKE/">Towards a Machine Learning-Assisted Kernel with LAKE</a>
</h1>
</header>
<div class="e-content article-entry" itemprop="articleBody">
<h1 id="Abstract"><a href="#Abstract" class="headerlink" title="Abstract"></a>Abstract</h1><p>摘要<br>现代操作系统（OS）的复杂性、硬件的快速多样化以及机器学习（ML）的稳步发展，促使我们探索 ML 在改进操作系统内核决策方面的潜力。我们猜想，ML 可以更好地管理内存管理、进程和 I/O 调度等子系统的权衡空间，这些子系统目前依赖手工调整的启发式方法来提供合理的平均性能。我们探讨了在五个内核子系统中用人工智能驱动的决策取代启发式方法的问题，并考虑了对内核设计、共享操作系统级组件和访问硬件加速的影响。我们确定了内核空间中出现的障碍，应对了挑战，并描述了 ML 所能提供的优势的权衡。我们发现，使用 GPU 等专用硬件对于吸收 ML 决策所需的额外计算负荷至关重要，但内核空间中加速器的可及性较差，这是采用 ML 的一个障碍。我们还发现，ML 和加速对操作系统的益处取决于子系统、工作负载和硬件，这表明在内核中使用 ML 将需要框架来帮助内核开发人员驾驭新的权衡空间。为了应对这些挑战，我们建立了一个名为 LAKE 的系统，用于在内核空间中支持 ML 和公开加速器。LAKE 包括用于跨抽象层和模块边界的特征收集和管理的 API。LAKE 提供了管理加速可变收益的机制，以及缓解用户空间和内核空间之间资源争夺的接口。我们的研究表明，通过加速，一个由 ML 支持的 I/O 延迟预测器的推理时间最多可缩短 96%。</p>
<h1 id="Intro"><a href="#Intro" class="headerlink" title="Intro"></a>Intro</h1><p>硬件的演变和多样化正在推动现代操作系统复杂性的爆炸性增长。CPU核心数量已经增长，新的内存技术如HBM和NVM以及像NUMA这样的组织已经变得司空见惯，新的网络和加速技术的出现，所有这些都对操作系统施加了压力，要求其进行高效的资源管理，以保持硬件的承诺。操作系统内核包含了用于管理这些资源的子系统，如内存管理器、I/O和进程调度以及文件系统，目前依赖于启发式方法来处理对性能至关重要的复杂权衡空间。这些启发式方法是通过观察系统行为、结合内核开发者的经验来开发的，目标是提供合理的平均情况性能。</p>
<p>随着硬件和软件复杂性的不断增加，机器学习（ML）已经成为一个有吸引力的替代方案，有潜力更好地导航当前由启发式方法处理的操作系统权衡空间。用ML替换启发式方法可以实现使用实时观察到的行为训练的系统特定解决方案。虽然已经提出了在操作系统子系统中使用ML支持的策略，如CPU负载平衡、文件系统预取、I/O延迟预测、控制CPU时钟和功率等，但以前的工作只关注了ML对单个子系统的潜在益处。我们则关注从将ML决策集成到操作系统内核中产生的系统挑战。</p>
<p>我们研究了五个可以用ML决策增强的基于启发式的内核子系统，包括进程调度、内存管理等。我们发现了一些重要的挑战，包括以下几点。C1 使用专用硬件如GPU/TPU对于降低ML算法的性能影响至关重要，但在内核空间中对加速器的可访问性较差是采用的障碍。加速器卸载在加速器是I/O附加时引入了额外的开销，并且在用户和内核空间使用加速器之间产生了新的争用形式。C2 对于ML的加速的好处是子系统、工作负载和硬件依赖的，因为硬件加速必须摊销数据传输的成本。C3 在抽象层边界和需要跨层数据共享以暴露用于训练和推理的特性之间存在基本的紧张关系。我们在这篇论文中解决了这些挑战，并分享了我们构建学习辅助、加速内核（LAKE）的经验。</p>
<p>为了解决C1，LAKE使用API远程调用为内核空间应用提供供应商支持的加速器接口（例如CUDA API），对于需要使用难以移植到内核空间的库的应用，提供自定义的高级API（例如TensorFlow）。LAKE通过在内核应用和用户空间组件之间进行零拷贝数据移动来减少开销。用户和内核空间对专用硬件的并发使用引入了争用，LAKE使用策略回调框架来管理这种争用。我们发现，管理这种争用所需的相同机制可以被重新用于解决C2，即专用硬件的可变利润性。LAKE提供了一个自定义的策略接口用于争用控制，当策略预测到争用或性能收益不足时，允许内核利用加速器或回退到较少的强度和/或基于CPU的解决方案。LAKE通过一个内核特性存储来解决C3，简化了为收集数据以通知训练和推理的内核子系统进行检测的任务，基于预期异步和抽象层边界等挑战的API。</p>
<p>我们的实验表明，LAKE为内核空间的ML支持的子系统提供了高效的硬件加速，可以减少内核的CPU利用率，并通过争用管理避免对用户空间应用的性能降级。例如，LAKE为ML辅助的I/O延迟预测提供了性能优势，将推理时间减少了高达95%，并将ML驱动的负载平衡推理加速提高了高达3.1倍。由于我们关注的是内核ML集成引起的系统问题，我们依赖于文献中的先前结果，这些结果展示了相对于启发式方法的ML支持策略的改进。然而，我们提出了一个端到端的IO调度案例研究，描述了加速的影响，发现ML的好处得以保留，硬件加速可以启用更丰富的模型。我们发现，LAKE的基础设施也可以用于启用ML领域之外的加速机会。我们评估了GPU加速的文件系统加密，发现潜在的读取吞吐量相对于AES-NI增加了高达62%，CPU利用率降低了高达64%。本文的贡献包括：<br>• 一个在内核空间暴露以ML为中心的硬件加速的框架（§4），具有管理争用（§4.3）和内核/用户空间硬件加速器共享的可变性能利润性（§4.2）的接口。<br>• 一个框架和高效的API，简化了在不同内核子系统中的特性收集和管理（§5）。<br>• 当由LAKE的基础设施驱动时，评估现有内核子系统的CPU利用率降低和性能提升（§7）。</p>
<p>2 背景<br>2.1 操作系统内核和机器学习<br>像Linux内核这样的单体内核，随着技术的发展，越来越多地积累了新的特性和责任。例如，Linux最初有一个简单的、贪婪的、时间片调度算法，只有一个任务列表。硬件的演变，例如核心数量的增加、超线程、非均匀内存访问（NUMA）和多个CPU插槽，迫使调度算法演变以支持这些特性。目前，Linux的调度器有一个更复杂的算法，使用自平衡树和每核任务列表，并必须在核心之间进行复杂的负载平衡以保持良好的利用率。这种问题维度的不断增加以及系统可以有不同特性的事实，使得设计高效的、通用的解决方案变得复杂，并导致启发式方法变得僵化，尽管需要解决各种各样的平台。</p>
<p>Linux内核依赖于启发式方法来做出重要的决策，例如回收哪个页面以及如何在CPU之间平衡进程。启发式方法通常是复杂的、计算密集型的、有时不切实际的（例如NP-hard问题）解决方案的便宜替代品。启发式方法的目标是快速得到一个足够好的（局部最小值或最大值）解决方案，而不是花费太多时间探索解决方案空间以寻找最优解。内核使用的启发式方法是一种一刀切的方法，目标是平均情况。例如，一个I/O密集型的服务器和一个计算密集型的服务器，如果使用相同的内核版本，都将使用相同的启发式方法；通过专门针对每个服务器的工作负载进行决策，性能可以得到改善。机器学习是这种固定启发式方法的一个可能的替代方案。</p>
<p>例如，在文件系统预取中，Leap显示，应用程序在文件访问模式上有很高的变化，导致固定的模式查找算法在许多情况下表现不佳。机器学习可以应用于文件系统预取，以改善启发式方法的不足。这可以通过在线学习文件访问模式，在执行过程中，训练自定义模型来实现。</p>
<p>2.2 加速器<br>专用加速器正在迅速增多：每年都会出现数十种新的特定目的的加速器和框架，以提高计算密集型工作负载的性能和效率。例如，GraphCore IPU和Google TPU等深度学习加速器可以提供比CPU高50倍的能效。近数据计算和分析，例如smartSSDs，将数据平面操作卸载到设备上，因为内部磁盘带宽远高于总线带宽。像GPU这样的通用加速器被广泛用于机器学习、生物信息学、加密货币等。</p>
<p>然而，当前的软件和系统对加速器的支持仅限于用户模式程序。加速器附带用户库和内核驱动，其接口和实现是专有的。尽管存在许多加速器虚拟化技术（例如，固定和中介传递，API远程调用），可以为应用程序提供虚拟GPU，但没有现有的解决方案可以直接被内核空间应用程序使用。</p>
<p>3 动机<br>我们将ML模型添加到操作系统内核的经验激励我们设计简化集成并赋予开发者使用可能计算密集的算法的基础设施。急需可以被当前和未来的通用应用使用的公共基础设施，以避免特定应用解决方案的增殖。一个关键的挑战是收集推理所需的特征数据，这可能需要在不同的抽象层、不同的模块中查询内核数据结构，这些模块具有不同的锁定规则。我们在第5节提出了一个API设计来应对这个挑战。我们还发现加速器（例如GPU）至关重要。它们的大规模并行性和高吞吐量使得可以实现更复杂和准确的模型；单独使用CPU往往无法满足性能要求。</p>
<p>不幸的是，加速器堆栈通常不会暴露内核空间API，而通常依赖于将专有的高级API支持因子化到用户空间的内核旁路设计。因此，以前的内核加速系统已经使用手工构建的上调用来启用操作系统级别的与加速器的交互。一般的加速器虚拟化技术，如API远程调用是不够的；这些系统使用的通信传输要么不可用，要么对内核和用户空间之间的数据传输效率不高。</p>
<p>将加速器暴露给内核空间揭示了操作系统和ML设置独特的机会和挑战。这个设置独特的关键挑战包括管理内核和用户空间应用程序之间对加速器的争用，减少跨用户-内核边界的不必要的数据移动，并使内核子系统能够根据性能和准确性的利润性在CPU和加速器之间调节。</p>
<p>争用和性能变化。内核ML工作可以与用户空间工作争用访问加速器设备，与跨用户空间进程争用不同，没有明确的机制来管理这种争用。此外，加速必须摊销数据传输成本才能获得性能利润，这需要对输入进行批处理，这可能与内核的延迟目标相冲突。这两种资源管理挑战对操作系统来说都是新的，但操作系统有一个回退的替代方案，即使用CPU。</p>
<p>对性能至关重要的用户应用程序需要稳定、可靠的访问专用硬件，以满足严格的截止期限。内核和用户空间之间对加速器的无节制的争用可能会破坏这些性能和QoS目标。图1演示了当GPU在一个由ML辅助的内核和一个计算绑定的用户进程之间共享时，由争用引起的性能病理现象。用户空间进程正在计算数据哈希，而内核使用GPU来加速页面热度分类和I/O延迟预测。如争用和移动平均线所示，内核和用户空间之间的争用严重影响服务质量。应用程序的吞吐量显著降低和不稳定，降低了高达68%。</p>
<p>数据移动。从内核空间调用用户空间API（通常通过上调用完成）需要对源上下文进行数据编组和复制到用户空间进程，并在完成后复制结果和修改的缓冲区。这可能导致在用户-内核边界上的冗余数据传输和不必要的同步，带来重大的性能损失（§6）。由于没有内核级接口可以将数据传输到加速器，因此必须首先将内核级数据缓冲区复制到用户空间，然后使用如cudaMemcpy等API将其复制到/从加速器。内核机制的智能组合允许自动数据编组和消除用户-内核边界上的数据传输的双缓冲。</p>
<h1 id="Motivation"><a href="#Motivation" class="headerlink" title="Motivation"></a>Motivation</h1><h3 id="设计简化集成的基础架构"><a href="#设计简化集成的基础架构" class="headerlink" title="设计简化集成的基础架构"></a>设计简化集成的基础架构</h3><h3 id="加速器堆栈不公开内核空间的应用程序API"><a href="#加速器堆栈不公开内核空间的应用程序API" class="headerlink" title="加速器堆栈不公开内核空间的应用程序API"></a>加速器堆栈不公开内核空间的应用程序API</h3><h3 id="内核ML工作会与用户空间工作争夺对加速器设备的访问权"><a href="#内核ML工作会与用户空间工作争夺对加速器设备的访问权" class="headerlink" title="内核ML工作会与用户空间工作争夺对加速器设备的访问权"></a>内核ML工作会与用户空间工作争夺对加速器设备的访问权</h3><h3 id="数据移动"><a href="#数据移动" class="headerlink" title="数据移动"></a>数据移动</h3><p>3.1 讨论<br>为什么不直接使用加速器的接口？虽然直接支持内核级加速器API是可能的，但频繁变化的内部接口和缺乏公开可用的文档使得对加速器软件堆栈的部分进行逆向工程变得不切实际。加速器软件堆栈的不透明性要求硬件供应商自己暴露内核级API。尽管NVIDIA最近开源了其驱动程序的一部分[7]，但驱动程序并未向内核暴露必要的高级API。我们还发现，ML支持通常更好地由像TensorFlow这样的高级API提供（§7），因此需要更通用的对上调用的支持。</p>
<p>设备能否直接管理争用？硬件供应商已经表现出他们愿意在硬件中启用一些争用管理。有一些加速器启用了单根I/O虚拟化（SR-IOV），一些设备如SmartNICs和SmartSSDs提供了用于粗粒度争用管理和速率限制的API，或者允许开发者表达他们自己的策略。然而，基于硬件的解决方案往往不够灵活。操作系统内核开发者可能希望动态地在不同的争用管理策略之间进行选择。复杂且不断演变的争用管理策略更容易在软件中表达，而我们的经验是，并非每个加速器都会在硬件中支持细粒度的争用管理策略。机器学习需要额外的策略支持来处理争用管理单独无法解决的性能利润性变化。</p>
<p>隔离是否受到影响？操作系统内核使用地址空间隔离作为他们的主要内存保护机制。我们依赖同样的机制来在将操作系统内核计算卸载到加速器时隔离内存。根据我们的经验，所有的加速器都支持某种类型的地址空间隔离。虽然任何将操作系统内核数据卸载到加速器的方法都可能暴露新的旁路通道，但我们将旁路通道缓解的调查留给未来的工作。</p>
<p>4 使用LAKE进行内核加速<br>为了允许在内核中使用依赖加速器的复杂机器学习算法，LAKE必须提供基础设施，使得未来和当前的内核空间应用能够使用加速器。目前这是不可能的，因为加速器供应商提供的库是为用户空间设计的。在LAKE中，启用加速器访问内核空间的核心是一个API远程调用系统，该系统向内核子系统公开任意API。LAKE公开的API通过用户空间的一个进程的上调用来执行。图2显示了LAKE的设计。我们考虑一个系统，其中Linux作为主机操作系统，并且至少有一个加速器。尽管这项工作主要关注NVIDIA GPU和CUDA，但没有根本的问题阻止它扩展到其他加速器[85]。</p>
<p>LAKE有三个主要组件：内核侧API提供者（lakeLib）、大量数据内核-用户通信通道（lakeShm）和实现API的用户侧守护进程（lakeD）。lakeLib是一个内核模块，它将加速器的供应商的用户空间库等API公开为内核空间的符号。这个模块有一个与它想要在内核空间支持的API同名的函数。例如，要在内核空间支持cuMemAlloc CUDA API，我们必须在lakeLib中有一个同名的函数。lakeLib中的每一个函数都做三件事：将API标识符和所有API参数序列化成一个命令，通过某个通信通道传输命令以在用户空间远程执行，最后，等待响应。</p>
<p>lakeD是一个用户空间的守护进程，它监听来自lakeLib的命令，对它们进行反序列化并执行请求的API。这个守护进程必须能够访问供应商的库（例如cudart.so）以实现lakeLib请求的API。继续cuMemAlloc API的例子，这样的API的一个命令包括一个字段，该字段标识要执行的API及其参数：要分配多少字节以及一个指针来存储新分配的起始地址。lakeD反序列化命令以获取这些字段，使用供应商的原始库执行API，并通过初始命令来自的同一通道发送回结果：返回码和API调用返回的指针。</p>
<p>最后，lakeShm是一个内核模块，为lakeLib和LAKE驱动的应用提供内存分配。通过lakeShm的API分配的内存被优化用于在内核空间应用和用户空间lakeD之间的数据传输。lakeShm通过请求和映射来自Linux内核的一个大的连续内存区域来工作。当lakeD启动时，同一区域被映射到它的进程。虽然仍然需要主机到设备的传输，但这允许在内核空间模块和lakeD之间进行零拷贝内存移动。</p>
<p>4.1 系统工作流程<br>当内核空间应用调用LAKE提供的API时，一系列机制被激活，直到最后由加速器处理。这个工作流程包括两个边界交叉：从内核到用户和从用户到内核空间。让我们考虑一个简单的应用，它在本地和GPU上分配内存，将本地数据复制到GPU，并调用一个内核在GPU上进行一些计算。我们研究的所有应用都执行这些步骤。</p>
<p>我们将使用LAKE的应用可以执行的操作分类为三类：本地操作、API远程操作和可复制内存分配。</p>
<p>本地操作：这些操作包括现有的内核函数和内核空间的内存分配。这样的操作不需要远程调用，也不会被LAKE修改。例如，常规的内存分配可以通过调用内核的内存分配器（例如vmalloc）来满足。</p>
<p>API远程操作：LAKE通过lakeLib将加速器API提供给内核空间。当应用调用一个加速器API时，执行流程切换到lakeLib模块。创建一个足够大的命令缓冲区来容纳API函数标识符（例如，一个数字）和所有函数参数。然后，这个命令通过一个类似于套接字的通道发送给lakeD。一旦在用户空间，命令被反序列化，请求的API在加速器上执行。完成后，构建一个带有返回值的返回命令并发送回来。执行API时产生的错误被转发给应用，应用必须进行自己的错误检查。</p>
<p>可复制内存分配：应用程序使用的将被复制到/从加速器的内存区域，应该使用lakeShm分配，它提供了一个类似于malloc的函数。通过lakeShm分配的内存区域是共享的，避免了内核和用户空间之间的内存复制。使用lakeShm本身并不能产生内核空间应用和加速器之间的零拷贝数据传输。例如，CUDA API有一个用户空间API（cudaMallocHost），它提供了从用户空间到GPU的零拷贝传输，但LAKE不能集成这个特性，因为CUDA运行时库是闭源的。对于LAKE提供的自定义高级API（在§4.4中讨论），其中内核空间应用调用的API比在加速器上分配内存的级别要高，lakeShm移除了其领域下唯一的数据复制。如果应用程序不使用lakeShm也不使用减少数据传输的加速器特定API，API远程调用仍然会工作；这只会导致额外的数据复制。</p>
<p>4.2 调节加速器使用<br>如我们在第7节中所示，使用加速器的盈利性并不总是有保证；加速器的大规模并行性只有在处理大量数据时才有优势。加速器在ML训练中几乎无处不在，因为它的批处理，但对于推理来说并非如此。对小批量输入的推理通常在CPU上更快。通常存在一个批量大小，在这个大小下，加速器会产生更好的性能（我们称之为交叉点）。</p>
<p>为了给内核ML应用提供最佳性能，LAKE允许在CPU和加速器之间进行即时切换，粒度为函数调用。这是通过自定义执行策略完成的（在第4.3节给出了一个例子）。LAKE允许开发者使用eBPF[4]编写和安装这样的策略。通过回调，开发者可以指定考虑使用加速器盈利的必要条件。策略在应用的执行过程中由内核自动执行。图3显示了一个简单的CUDA设备策略的伪代码，该策略通过在批量大小低于某个阈值时回退到CPU来管理可变的盈利性。</p>
<p>4.3 争用管理<br>我们不能假设LAKE提供的加速器将仅供内核使用。用户空间应用期望从加速器获得性能保证，我们不能容忍性能干扰。当加速器成为一个争用的资源时，内核空间应用必须减少或完全停止使用加速器，并回退到一个更简单、强度较小的加速器实现或CPU实现。</p>
<p>用于调节加速器利用率的相同策略可以用于管理争用。策略的工具集包括任何操作系统或供应商提供的实用程序（例如，由LAKE支持的NVIDIA的NVML API），允许对系统当前状态的细粒度信息。图3显示了一个简单的CUDA设备争用策略的伪代码。该策略对GPU利用率的查询进行速率限制，并使用移动平均数来保持内核对GPU计算的消耗在一个阈值以下。开发者可以用两个回调函数来指定策略：dev_func回调通常包含一个或多个cuLaunchKernel调用，而cpu_func可以包含执行相同计算的替代API，但可能在CPU上操作或使用较少的加速器资源。</p>
<p>4.4 高级API 现有的机器学习库（如 Tensorflow）的简单性，将复杂的机器学习功能抽象为高级API，使得应用程序不倾向于直接使用CUDA运行时API。虽然可能，但我们不能强迫开发者在CUDA中实现复杂且难以优化的算法。同时，将像Tensorflow这样的庞大库移植到内核是不切实际的；这些库依赖于用户空间专有的库，并且体积庞大。使内核能够使用机器学习是LAKE的主要目标之一，因此我们必须为应用程序提供使用高级库的机制。</p>
<p>LAKE的API远程系统足够通用，可以支持手动添加API。这是必需的，以允许内核空间应用程序使用高级API，而无需将它们移植到内核空间。例如，我们的页面热度预测器（§ 7.2）基于Kleio，它使用Tensorflow构建了一个包含两个LSTM层的模型。虽然构建模型并不困难，但使用CUDA运行时直接实现快速、高效和正确的LSTM推理却是。向内核空间提供高级API需要两件事：在lakeLib中添加函数的原型，并在lakeD中实现其功能。手动添加API需要开发者设计从内核中的原始数据到库期望的数据的转换。例如，如果NumPy数组被用作TensorFlow的输入，这在内核中是不可用的，数据必须以某种格式（例如，数字数组）发送并在lakeD中转换。LAKE提供了内核和用户空间之间的自动数据序列化。<br>API Description<br>create_registry(name, sys, schema, window) Creates feature registry with capacity<br>destroy_registry(name, sys) Destroys a feature registry<br>create_model(name, sys, path) Create a new ML model, saved at path<br>update_model(name, sys, path) Commit a changed model to the file system<br>load_model(name, sys, path) Load a model from path into memory<br>delete_model(name, sys, path) Delete a model from the file system and memory<br>register_classifier(name, sys, fn, arch) Provide a function pointer for classifiers/inference<br>Note: arch specifies CPU / GPU / XPU<br>register_policy(name, sys, fn) Provide an eBPF policy for contention/batching (§4.3)<br>score_features(name, sys, fvs, num) Run inference on a batch, return batch results<br>get_features(name, sys, ts) Batch retrieves all feature vectors older than ts<br>begin_fv_capture(name, sys, ts) Starts the creation of a new feature vector.<br>Subsequent calls to capture_feature for name/subsystem<br>will add/overwrite the current value of that feature<br>capture_feature(name, sys, key, val, sz) Sets feature with key, val on the current vector<br>capture_feature_incr(name, sys, key, incrval, sz) Update a feature with key by incrementing<br>commit_fv_capture(name, sys, ts) Commits the current feature vector to the registry.<br>truncate_features(name, sys, ts) Removes all feature vectors older than ts</p>
<p>5 内核特性注册表<br>LAKE支持内核特性注册表，用于管理机器学习模型和特性向量捕获，其API显示在表1中。API的设计目标是：1)最小化机器学习相关功能的性能影响，2)在抽象和模块边界存在的情况下，启用简单、可能异步的特性向量捕获，并预见多线程代码的需求（例如，需要在持有锁或在中断上下文中查询相关的数据结构吗？）以及3)简化对特性向量批次进行推理的任务。一般来说，API提供了一些函数，用于管理注册表（与内核子系统关联的模型的命名组合，附带特性向量模式）、管理机器学习模型、捕获特性和调用分类器/推理。</p>
<p>5.1 针对性能的设计<br>API通过在内核中操作并使用精心设计的数据结构和API设计来实现第一个目标（最小开销）。机器学习模型被提交到文件系统，并在启动时加载到内存中。加载和更新是不频繁的，所以文件系统开销是可以接受的，但在推理时，将模型放在内存中对性能至关重要。特性向量存储在内存中的一个循环缓冲区中，大小根据指定的窗口参数进行设置，一般格式为<numfeatures, kvpair*, ts_begin, ts_end>。kvpair*是一个从特性键到由无锁哈希表支持的值的键值映射。我们考虑在用户空间支持特性注册表，以避免在内核中引入敏感代码，但最终决定，为了捕获特性和访问推理模型，内核交叉会在关键路径上带来过多的开销。</p>
<p>5.2 模式<br>每个注册表都有一个模式，描述了特性向量的格式：具体来说，模式是从特性键（名称）到<size, entries>元组的映射，其中size是特性类型所需的字节数（例如，int需要4字节），entries为包含历史值的特性向量提供数组支持。LAKE避免跟踪特性向量条目的实际值类型，而是提供必要的容量并将值视为无类型的字节。对于大多数特性类型，例如整数值，entries为1，意味着向量包含一个单一的标量值。当entries大于1时，特性是一个长度为entries的数组，其中索引0处的条目是最近的样本，索引1..(N−1)处的条目是最后N−1个特性向量的历史样本。我们发现，包含特定值的最后N次测量的特性足够常见，以至于在API级别提供对这种习语的支持是一种值得的简化。这种习语的一个例子在下面的案例研究中有所说明（§5.5）。</p>
<p>5.3 异步和模块边界<br>为了理解上述的设计目标2，考虑到同步特性捕获（在调用推理之前查询相关数据结构）可能是不切实际的，因为模块边界和锁定规则可能使访问广泛分散的数据变得不切实际。LAKE通过一个异步API来解决这个问题，该API允许程序员在已经维护了被测量数据的代码站点放置简单的调用，随着时间的推移构建特性向量。注册表依赖于无锁数据结构，以便在任意内核线程上启用测量调用，而不需要额外的锁定规则。API支持一种习语，即特性捕获打开（调用begin_fv_capture()）：当特性捕获打开时，可以在任何线程上使用capture_feature()捕获单个特性向量值，该函数更新特性映射（kvpair）中给定键的值。我们发现，对于内核开发者来说，有些情况通过支持特性值的增量更新（使用capture_feature_incr()）可以显著简化（参见下面的例子：§5.5）。创建一个新的特性向量会设置一个开始时间戳（ts_begin），而捕获通过提交来最终确定，这会设置一个结束时间戳（ts_end）。</p>
<p>5.4 简化批处理管理<br>因为机器学习的性能-准确性的盈利能力是可变的，我们发现，对批处理大小的明确控制是暴露给内核开发者的一个关键参数，以调节加速器的使用。使用时间戳ts查询注册表（get_features()）会返回第一个满足ts_begin <= ts <= ts_end的特性向量。使用空时间戳查询会返回包含循环缓冲区中所有特性的批处理。API可以通过调用truncate_features()来确认消费了该批处理。当注册表的模式具有依赖于历史样本的特性（上述entries > 1），LAKE将始终在截断时保留最近的特性向量，以便系统正确地填充那些特性值。score_features() API调用程序员定义的回调（用register_classifier()指定）来运行推理。由框架调用的策略函数（用register_policy()指定）用于管理加速器的使用。</p>
<p>5.5 特性注册表案例研究<br>在具有并行和冗余存储（例如，RAID）的系统中预测I/O延迟可以通过拒绝高延迟的I/O并将相同的I/O重新发给不同的设备来提高吞吐量。我们在§7中测量了这个工作负载，但在这里使用它来说明特性注册表API的使用。捕获与I/O延迟相关的特性需要在I/O的边界处插入代码，这些代码的位置与调用推理的位置不同，因此需要支持异步特性构造。在I/O发出时调用推理，并根据包含挂起I/O的数量和固定数量的先前I/O的完成延迟的特性向量将系统分类为快或慢。</p>
<p>捕获挂起I/O的数量和I/O的延迟需要开发者在I/O发出和完成时插入代码。清单4显示了添加到generic_make_request_checks函数的伪代码，该函数在I/O发出时被调用，以便捕获系统的当前状态作为一个特性向量。我们存储了这个I/O发出的时间（需要计算延迟），增加了当前特性向量中的挂起I/O的数量，并提交了当前状态作为一个特性向量。然后，如果预定义的时间量子已经过去或者我们达到了期望的批处理大小，我们从注册表中检索一批处理，执行批处理推理，根据每个I/O的结果采取行动，并清除特性注册表环。特性也必须在I/O完成时被捕获。清单5显示了添加到bio_endio函数的伪代码，该函数计算当前I/O完成所需的时间，将挂起的I/O数量减少一个，并更新当前的特性向量。</p>
<p>延迟预测在特性构造中具有明显的异步性，特性值可以方便地在不同的线程上捕获。I/O可以由内核并发处理，手动的状态管理和特性向量的构造需要仔细的并发控制。LAKE的特性注册表简化了这些问题。</p>
<figure class="highlight c"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br><span class="line">19</span><br><span class="line">20</span><br><span class="line">21</span><br><span class="line">22</span><br><span class="line">23</span><br></pre></td><td class="code"><pre><span class="line"><span class="number">1</span> <span class="comment">// 在Linux中发出块I/O时调用</span></span><br><span class="line"><span class="number">2</span> generic_make_request_checks ( <span class="keyword">struct</span> bio *bio )</span><br><span class="line"><span class="number">3</span> {</span><br><span class="line"><span class="number">4</span> sys = <span class="string">" bio_latency_prediction "</span></span><br><span class="line"><span class="number">5</span> <span class="comment">// 存储这个I/O的开始时间</span></span><br><span class="line"><span class="number">6</span> getnstimeofday (&( bio - > io_start_ts ) ) ;</span><br><span class="line"><span class="number">7</span> <span class="comment">// 在这个设备上增加挂起的I/Os</span></span><br><span class="line"><span class="number">8</span> capture_feature_incr ( dev , sys ,<span class="string">" pend_ios "</span> ,<span class="number">1</span>)</span><br><span class="line"><span class="number">9</span> <span class="comment">// 这个I/O变成一个特性向量</span></span><br><span class="line"><span class="number">10</span> commit_feature_capture ( dev , sys , now () )</span><br><span class="line"><span class="number">11</span> <span class="keyword">if</span>( quantum passed or batch > thresh ) {</span><br><span class="line"><span class="number">12</span> <span class="comment">// 获取环中的所有特性向量</span></span><br><span class="line"><span class="number">13</span> fvs = get_features ( dev , sys , <span class="literal">NULL</span> )</span><br><span class="line"><span class="number">14</span> <span class="comment">// 对所有特性向量进行推理</span></span><br><span class="line"><span class="number">15</span> scores = score_features ( dev , sys , fvs ) ;</span><br><span class="line"><span class="number">16</span> <span class="comment">// 拒绝，重新发出或接受I/Os</span></span><br><span class="line"><span class="number">17</span> ...根据分数采取行动...</span><br><span class="line"><span class="number">18</span> <span class="comment">// 重置特性向量环</span></span><br><span class="line"><span class="number">19</span> truncate_features ( dev , sys , <span class="literal">NULL</span> )</span><br><span class="line"><span class="number">20</span> }</span><br><span class="line"><span class="number">21</span> <span class="comment">// 开始新的特性</span></span><br><span class="line"><span class="number">22</span> begin_fv_capture ( dev , sys , now () )</span><br><span class="line"><span class="number">23</span> ...</span><br></pre></td></tr></table></figure>
<p>图4：使用LAKE特性注册表进行I/O延迟预测的I/O发出代码的伪代码。每个块设备都需要自己的特性注册表（name参数是设备的名称，例如sda1）。</p>
<figure class="highlight c"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br></pre></td><td class="code"><pre><span class="line"><span class="number">1</span> <span class="comment">// 调用函数以结束块I/O</span></span><br><span class="line"><span class="number">2</span> <span class="type">void</span> <span class="title function_">bio_endio</span> <span class="params">( <span class="keyword">struct</span> bio *bio )</span> {</span><br><span class="line"><span class="number">3</span> sys = <span class="string">" bio_latency_prediction "</span></span><br><span class="line"><span class="number">4</span> <span class="comment">// 获取这个I/O的延迟</span></span><br><span class="line"><span class="number">5</span> lat = get_io_latency ( bio - > io_start_ts ) ;</span><br><span class="line"><span class="number">6</span> <span class="comment">// 存储这个I/O的延迟</span></span><br><span class="line"><span class="number">7</span> capture_feature ( dev , sys , io_latencies , lat ) ;</span><br><span class="line"><span class="number">8</span> <span class="comment">// 在这个设备上减少一个挂起的I/O</span></span><br><span class="line"><span class="number">9</span> capture_feature_incr ( dev , sys , pend_ios , <span class="number">-1</span>)</span><br><span class="line"><span class="number">10</span> ...</span><br></pre></td></tr></table></figure>
<p>图5：使用LAKE特性注册表进行I/O延迟预测的I/O完成代码的伪代码。</p>
<p>6 实现<br>我们的LAKE原型基于Linux内核版本6.0。默认情况下，内核不支持机器学习算法所需的浮点运算。需要使用浮点数的代码区域必须用启用它的宏（kernel_fpu_begin和kernel_fpu_end）进行包装。</p>
<p>LAKE的API远程系统为内核空间提供了CUDA驱动API版本11.0以及TensorFlow 2.4.0和Keras 2.2.5。</p>
<p>LAKE的API远程系统的实现类似于一个RPC系统：lakeLib向内核导出符号（存根），lakeD是处理传入请求的用户空间进程。这两者之间发送的命令通过Netlink套接字进行传输，因为它们的延迟很低。较大的内存传输通过零拷贝共享内存机制完成。</p>
<p>通信通道。LAKE需要高效的通信通道，因为应用程序可能对调用或延迟敏感。Linux提供了内核-用户通信的机制，如ioctl、系统调用、信号、上行调用、mmap和套接字。我们在表2中评估了这些替代方案，该表总结了从内核向用户空间发送门铃的调用时间和延迟。除mmap外，所有机制的延迟都相似，而设备读/写和Netlink有额外的缓存或排队层。mmap方法最快，但会浪费CPU旋转，所以我们使用Netlink套接字。</p>
<p>表2：从内核向用户发送门铃消息的平均调用时间和延迟。<br>信号 设备R/W Netlink Mmap<br>调用时间（微秒） 56 6 11 6<br>延迟（微秒） 56 57 54 6</p>
<p>映射内存。内核和用户空间之间的批量数据传输是通过lakeShm完成的，lakeShm在加载时通过dma_alloc_coherent预留了一个连续的DMA区域。使用了基于最佳适应的内存分配器算法。使用映射内存可以避免在内核-用户边界上传输大的数据缓冲区。图6显示了不同大小的消息的往返传输成本。传输较大的消息会导致大的开销，这可以通过lakeShm来消除。</p>
<p>6.1 讨论：安全性影响<br>LAKE引入了一个用户空间组件，将内核的私有数据通过用户空间移动，以便将加速器暴露给用户空间。在LAKE中，用户空间守护进程是一个受信任的进程，它以root身份运行，类似于任何其他与内核紧密集成的用户空间守护进程（例如，典型的微内核、用户模式设备驱动程序的用户空间内存管理器、调度器和文件系统，这些在现代操作系统如Windows中很常见）。地址空间分离提供了强大的安全保证，防止数据泄露，尽管守护进程并未在内核模式下执行。尽管如此，为了获得额外的保证，用户空间守护进程（lakeD）可以被沙箱化，并可以使用seccomp。lakeD守护进程与操作系统的接口相当有限（它需要ioctl和mmap用于lakeShm，netlink套接字用于lakeLib，以及由CUDA运行时完成的系统调用）。虽然我们在这项工作中并未考虑侧通道，但lakeD可以扩展以使用像Graviton[79]或Telekine[35]这样的安全GPU TEE。</p>
<p>6.2 源代码<br>总的来说，lakeLib、lakeShm（都是内核空间代码）和lakeD（用户空间代码）分别由大约817、826和1072行的C/C++代码组成，另外还有769行的代码用于核心公共功能。我们用于预测I/O延迟的神经网络及其工具包含大约4157行代码。其他工作负载和修改过的eCryptfs分别包含1400和2925行代码。LAKE是在GPLv3下的开源项目，可以在GitHub上的utcs-scea/LAKE找到。</p>
</div>
<footer class="article-footer">
<a data-url="https://worstkid92.github.io/papers.github.io/2023/12/20/Towards-a-Machine-Learning-Assisted-Kernel-with-LAKE/" data-id="clqk8x1930000akva9x9d5rq2" data-title="Towards a Machine Learning-Assisted Kernel with LAKE" class="article-share-link"><span class="fa fa-share">Share</span></a>
</footer>
</div>
</article>
<article id="post-Toward-Reconfigurable-Kernel-Datapaths-with-Learned-Optimizations" class="h-entry article article-type-post" itemprop="blogPost" itemscope itemtype="https://schema.org/BlogPosting">
<div class="article-meta">
<a href="/papers.github.io/2023/12/08/Toward-Reconfigurable-Kernel-Datapaths-with-Learned-Optimizations/" class="article-date">
<time class="dt-published" datetime="2023-12-08T06:34:10.000Z" itemprop="datePublished">2023-12-08</time>
</a>
</div>
<div class="article-inner">
<header class="article-header">
<h1 itemprop="name">
<a class="p-name article-title" href="/papers.github.io/2023/12/08/Toward-Reconfigurable-Kernel-Datapaths-with-Learned-Optimizations/">Toward Reconfigurable Kernel Datapaths with Learned Optimizations</a>
</h1>
</header>
<div class="e-content article-entry" itemprop="articleBody">
<h1 id="Abstract"><a href="#Abstract" class="headerlink" title="Abstract"></a>Abstract</h1><p>作者提出了一种使内核能够自我优化的架构。在这种架构中，优化是通过使用机器学习（ML）从经验数据中计算出来的，并通过内核虚拟机以安全和系统化的方式集成到内核中。这个虚拟机实现了可重新配置的匹配表（RMT）抽象，其中表格被安装到内核中，当性能关键事件发生时，匹配查找当前的执行上下文，动作编码由ML计算出的上下文特定优化，这可能会因应用程序而异。他们设想的架构将支持离线和在线学习算法，以及各种内核子系统。RMT验证器将在将RMT程序接纳到内核之前检查程序的良好形式和模型效率。一个被接纳的程序可以被解释为字节码或即时编译以优化内核数据路径。</p>
<h1 id="1Inteoduction"><a href="#1Inteoduction" class="headerlink" title="1Inteoduction"></a>1Inteoduction</h1><p>操作系统内核正面临来自上下的压力。作为通用资源管理器，操作系统内核需要支持不同的应用，并需要在不同类型的硬件平台上进行多路复用。近来，应用和硬件平台都在快速多样化。<br>例如，在应用方面，容器或微服务工作负载对延迟敏感，而类似MapReduce的数据处理任务则以IO密集型（例如，用于批量同步、检查点或恢复）的吞吐量为导向。家庭用户应用程序（例如，文档或照片编辑软件）是另一类，具有自己复杂的磁盘IO模式和与云的频繁交互。这种复杂性确保了不存在一种适合所有场景的优化策略。<br>同样，硬件技术的发展速度超过了软件系统栈，每一代的特性都有所不同，甚至每一代内部，不同供应商的产品也有所不同。对硬盘最好的IO调度算法对SSD和密度优化的覆盖磁盘来说肯定会表现不佳。更进一步复杂化的是，设备正在变得更智能，封装了运行专有算法的嵌入式控制器进行本地管理。在设备中运行这些无法控制的黑箱代码可能会混淆甚至最优化的内核优化。<br>这两种趋势的汇合要求我们从根本上重新思考操作系统内核应如何为特定场景专门化以提高性能，以及这些专门化如何推广到可能出现的未见过的场景。最近的两种方法可以被视为接近这个目标。内核绕过方法认为资源管理最好留给应用程序。用户态应用程序被直接访问网络卡或磁盘（例如，使用DPDK/SPDK），并根据需要实现自己的优化。另外，eBPF允许应用程序动态地将受限的代码注入到内核中进行定制，以达到类似的效果。<br>然而，这两种方法都没有回答在什么时候应该实施什么优化的问题。应用程序可能没有足够的知识来充分地实现好的优化，任何改变可能会被新的硬件所无效。当各个应用程序选择自己的策略时，内核也失去了进行跨应用程序优化所需的集中视图。<br>我们的愿景：可重新配置的内核数据路径。在这篇论文中，我们主张一种根本不同的方法，并提供了一个答案，这个答案从两个最近的工作中得到启发——越来越强大的机器学习（ML）技术，以及使用可重新配置的匹配表（RMT）专门化网络堆栈的努力。我们的关键思想是开发可重新配置的内核数据路径，其中的机制基于内核中的RMT风格的架构，策略是使用ML学习的。操作系统内核动态地以RMT程序的形式发现每个场景的最佳策略，并通过配置内核虚拟机来执行这些策略。通过将这种可编程但轻量级的原语转化为操作系统内核，我们提供了一种允许各种类型适应性的架构。通过利用ML的力量，我们可以消除今天的内核数据路径中大量的最佳努力启发式方法，并使优化能够推广到未见过的应用、工作负载或硬件平台。<br>在20世纪90年代，应用特定的内核优化和扩展得到了深入的研究。Exokernel主张完全消除操作系统抽象，并将其实现留给应用程序。另一方面，SPIN允许应用程序将安全代码注入到内核中进行动态扩展。他们与内核绕过和eBPF注入的现代等价物有类似的限制。相比之下，我们的想法的一个关键目标是通过基于ML的重新配置自动识别内核优化，因此应用程序不再需要以一次性的方式专门化内核。<br>研究挑战。实现我们的可重新配置内核数据路径的愿景需要应对一系列挑战：将RMT风格的虚拟机架构到内核中，开发轻量级的内核学习算法，以及将架构应用到关键的内核子系统（例如，调度、内存管理、文件系统、网络）。我们希望在减少操作系统税收方面取得显著的进展：据报道，内核执行占据了数据中心CPU周期的20%，而数据中心代表了全球电力消耗的1%。因此，提高操作系统内核的效率对于广泛的部署场景具有重要的意义。</p>
<h1 id="2Motivation"><a href="#2Motivation" class="headerlink" title="2Motivation"></a>2Motivation</h1><p>机器学习技术在计算机系统中取得了早期但成功的结果，取代了用于数据检索的精心调整的索引结构，预测硬件设备状态以实现更好的管理，以及有效地管理C++对象内存。张和黄认为，机器学习应该应用到操作系统内核中。我们的想法受到了这项工作的启发，它提出了一种系统化的方法，通过RMT虚拟机将机器学习集成到内核中。</p>
<h2 id="2-1-预期的好处"><a href="#2-1-预期的好处" class="headerlink" title="2.1 预期的好处"></a>2.1 预期的好处</h2><p> 我们相信，可重配置的内核数据路径有可能释放出四类在今天的操作系统内核中难以实现的好处。</p>
<h3 id="1-精简监控："><a href="#1-精简监控：" class="headerlink" title="1. 精简监控："></a>1. 精简监控：</h3><p>操作系统内核使用了大量的运行时监控器，目的是描述当前的工作负载并激活不同的内置启发式算法。然而，这些监控事件引入了缓存污染、运行时开销，而且在某些情况下，它们通过故意引起一些性能下降来工作。后者的一个例子是在NUMA机器上的CPU调度器——为了检测内存亲和性，调度器需要监控线程的页面级访问模式；Linux通过周期性地取消映射进程的页面来做到这一点，这样内核就可以捕获页面错误并监控访问位置。通过引入机器学习，我们可能可以使内核减少必要的监控。例如，使用特征重要性排名[33]的特征选择过程可能允许内核放弃监控那些提供的信息很少的事件。 </p>
<h3 id="2-更好的配置："><a href="#2-更好的配置：" class="headerlink" title="2. 更好的配置："></a>2. 更好的配置：</h3><p>操作系统内核中的启发式算法和配置参数的广泛范围可能并不是最优的；调整内核参数以实现更好的配置也是一项具有挑战性的任务。此外，启发式算法只有在引导阶段之后才会被激活（例如，这个特定的线程是I/O绑定的吗？那么就提高它的调度优先级）。在我们的设计中，机器学习算法应该能够探索更广泛的决策策略，从而得到更好的配置参数、明智的策略和更高的性能。如果操作系统内核可以预测应用程序的行为，那么引导阶段可能会被缩短甚至消除，只要应用程序启动，就激活一个合适的配置。配置参数和策略也可以在应用程序运行时进行调整，而不是静态地配置到内核中。</p>
<h3 id="3-泛化："><a href="#3-泛化：" class="headerlink" title="3. 泛化："></a>3. 泛化：</h3><p>机器学习的另一个强大特性是它能够对某些任务的未见过的数据点进行泛化[38]。用机器学习模型替换内核中手工制作的、特定的启发式算法可能会导致更稳健的决策。在今天的内核中，展示新行为的应用程序，这些行为没有被现有的启发式算法捕获，通常会有不透明和不可预测的性能。这些性能悬崖只能通过广泛的、通常是针对特定应用的基准测试，由内核开发社区在一段时间内慢慢地捕获和修复。 </p>
<h3 id="4-跨应用优化："><a href="#4-跨应用优化：" class="headerlink" title="4. 跨应用优化："></a>4. 跨应用优化：</h3><p>此外，我们的愿景使内核能够学习多个应用程序的行为，它们之间的关系，以及联合优化的机会。这些跨应用的优化将导致更好的系统范围的资源分配。例如，监控可能会检测到任务表现出生产者-消费者行为，并激活优化以实现有效的通信。 当然，机器学习并不是灵丹妙药——一般来说，需要谨慎地将正确的学习技术与正确的问题相匹配[38]。同样的原则也应该适用于操作系统内核：机器学习的有效性将自然地根据手头的任务而变化，在某些情况下，精心调整的启发式算法可能已经走得很远。我们的立场是，机器学习技术在操作系统内核的背景下具有重大的前景，这篇论文是对更彻底的调查的号召。</p>
<h2 id="2-2-为什么选择RMT？"><a href="#2-2-为什么选择RMT？" class="headerlink" title="2.2 为什么选择RMT？"></a>2.2 为什么选择RMT？</h2><p>为了利用机器学习，我们需要一个适合将其集成到内核的架构。这样的架构必须满足一系列的属性：<br>• 足够通用：我们需要一个通用的架构，可以表示不同类型的重配置需求，适用于各种内核组件，也适用于学习的不同阶段（例如，数据收集、训练和推理）。<br>• 受限的：重配置的形式必须受限，以便人们可以轻松地推理和验证配置的正确性，然后再将其安装到内核中。<br>• 轻量级的：它应该能够以小的运行时开销实现高效的重配置。理想情况下，它应该是硬件友好的，以便可以将其合理地集成到CPU架构中，就像页面表遍历器已经被标准化到硬件中一样。<br>我们提出的答案是基于可重配置匹配表（RMT），这是网络社区中的一项最近的发展，专门用于专门化网络数据平面。一个RMT程序由一系列可重配置表的管道组成，其中进行专门的数据包处理。表的执行执行匹配，检查一个或多个数据包头字段，并触发基于匹配结果激活不同处理的动作。RMT编程模型受限，但对于广泛的重配置场景来说足够通用，并且已经被证明在高速（Tbps）下是可行的。这些属性使RMT成为内核重配置的有吸引力的候选者，其中存在类比：表是决策点（例如，预取），匹配检查当前的执行环境（例如，过去的访问模式），动作咨询一个机器学习模型（例如，预测要预取的下一组页面）。</p>
<h1 id="3-可重配置内核数据路径"><a href="#3-可重配置内核数据路径" class="headerlink" title="3 可重配置内核数据路径"></a>3 可重配置内核数据路径</h1><p>在这一部分，我们描述我们的设计，它的研究挑战，以及暂定的解决方案。</p>
<h2 id="3-1-内核中的RMT虚拟机"><a href="#3-1-内核中的RMT虚拟机" class="headerlink" title="3.1 内核中的RMT虚拟机"></a>3.1 内核中的RMT虚拟机</h2><p>一个RMT程序是由机器学习从过去或当前的运行中产生的，并且它是从用户空间注入到内核的。该程序在虚拟机中以解释模式运行，或者它是即时（JIT）编译为机器代码以提高效率。许多机制类似于eBPF [49]，但RMT程序与eBPF的形式不同，因为它们是为机器学习定制的。</p>
<h3 id="RMT程序。"><a href="#RMT程序。" class="headerlink" title="RMT程序。"></a>RMT程序。</h3><p>RMT程序的关键构建块是匹配/动作表的管道。每个表代表一个内核挂钩点，可能会触发关于当前执行的数据收集，拦截性能关键的内核事件，或者根据执行上下文咨询机器学习模型。一个RMT程序可以用受限的C或特定领域的语言编写，并编译成机器无关的字节码，通过系统调用安装。程序验证器检查良好的形式和有界的执行，并阻止任意的内核调用或数据修改。RMT字节码可以进一步被即时编译直接为机器代码以提高效率。在运行时，一个RMT程序可以访问一组受限的内核函数，这些函数专门用于学习和推理。它还可以访问存储执行上下文、历史数据和机器学习模型本身的内核内存。</p>
<h3 id="表格"><a href="#表格" class="headerlink" title="表格"></a>表格</h3><p>每个表格代表内核数据路径中的一个关键决策点，即内核执行和适应性的关键路径。表格的数量、决策的类型以及安装这些表格的位置都是可配置的。例如，rmt_table page_patterns 可能会插入到内存子系统的 lookup_swap_cache 函数中，以收集交换区域的页面访问模式的数据；稍后，rmt_table page_prefetch 被插入到 swap_cluster_readahead 函数中，以预测下一组要预取的页面。每个表格都包含一组匹配/动作条目，这些条目可以在 RMT 程序中静态编码，也可以在运行时通过 API 动态插入或删除。</p>
<h3 id="匹配-动作条目"><a href="#匹配-动作条目" class="headerlink" title="匹配/动作条目"></a>匹配/动作条目</h3><p>每个条目代表一个决策控制流。例如，为了收集每个文件的访问模式，当文件被打开时会插入新的条目。另一组条目可能会监视每个应用程序的模式，当应用程序被创建时会插入条目。条目的匹配字段控制模式匹配方法，例如，对于每个文件的条目，使用 inode 数字，对于每个应用程序的条目，使用 PID。条目也可能是聚合的，例如，每个子目录或 cgroup。我们称这些匹配字段为“执行上下文”，这些信息被组织在键/值映射的 RMT_CTXT 类型中，并可以使用匹配键检索。本质上，执行上下文类似于今天的内核监控数据，但是模式匹配剥离了不必要的监控，只保留了对决策至关重要的监控。这也是在系统范围内的常数时间，无需遍历复杂的内核数据结构。在底层，表格匹配被编译成 RMT 字节码指令，如内存访问（例如，RMT_LD_CTXT）和计算指令（例如，RMT_MATCH_CTXT）。动作可能会修改执行上下文（例如，追加到访问模式历史）使用像 RMT_ST_CTXT 这样的指令，或者它可能会使用 CALL 指令调用 ML 模型。</p>
<h3 id="更新-RMT-条目"><a href="#更新-RMT-条目" class="headerlink" title="更新 RMT 条目"></a>更新 RMT 条目</h3><p>RMT 数据路径代表决策点，但其策略是通过控制平面 API 重新配置的。此 API 支持添加、删除、修改匹配/动作条目和 ML 模型。例如，ML 训练组件可能会定期更新表格条目以反映最新的监控数据，例如，为新启动的应用程序添加额外的表格条目。或者，控制平面依赖过去的预测准确性来检测工作负载变化并调整表格条目。例如，如果预取的准确性低于阈值，控制平面将重新计算 ML 决策以在预取时更保守，并重新配置 RMT 表格以反映工作负载变化。</p>
<h3 id="RMT-数据结构"><a href="#RMT-数据结构" class="headerlink" title="RMT 数据结构"></a>RMT 数据结构</h3><p>虚拟机还提供了一组额外的数据结构用于内核 ML。这包括用于监控目的的数据结构（例如，类似于不同类型的 eBPF 地图），以及用于训练和推理的数据结构（例如，决策树，NN）。将添加标准接口到这些数据结构，使它们可以被不同的内核子系统以及用户空间访问。</p>
<h2 id="3-2-内核中的轻量级-ML"><a href="#3-2-内核中的轻量级-ML" class="headerlink" title="3.2 内核中的轻量级 ML"></a>3.2 内核中的轻量级 ML</h2><p>如上所述，ML 数据结构（例如，conv_layer）和辅助函数（例如，matrix_multiply）的库可以帮助 RMT 程序构建更复杂的 ML 模型（例如，action_cnn）。这些动作也是从 RMT 表格中触发的，并且被编译成具有专用 ML 指令集（例如，RMT_VECTOR_LD，RMT_MAT_MUL，RMT_SCALAR_VAL）的 RMT 字节码，这种指令集是根据神经处理器的硬件 ISA 模式化的。可以将模型添加到这个库中，但是它们必须满足一组性能要求（例如，NN 层的数量，内存访问，或浮点运算）。RMT 验证器将静态检查模型，例如，通过计算输入特征图的高度、宽度和通道数的卷积层的浮点运算数，然后将其 JIT 编译为机器代码。在计算预测结果（例如，要预取的页面数）后，基于 ML 的动作将退出 RMT 管道并进入常规内核执行。在需要时，模型也可以使用 TAIL_CALL 进行级联。</p>
<p>对于内核 ML 存在几个研究挑战。<br>ML 训练。我们的目标是在内核中支持离线和在线、实时训练。它们涉及到不同的挑战。离线训练可以以异步的方式进行，因此不会对内核工作负载产生额外的开销。然而，以在线方式进行实时训练可以更好地处理快速变化的工作负载和场景。实际上，实时学习是 ML 社区的一个最近的趋势，有许多未解决的问题和正在进行的研究工作。它在操作系统内核中的使用带来了更多的挑战，尤其是关于延迟的问题。例如，自动驾驶汽车的决策系统可能需要几毫秒，但是 CPU 调度的延迟要求在微秒级别。此外，离线训练可以在成熟的库和框架中进行，并且可以从 GPU 或 TPU 支持中受益。另一方面，操作系统内核内的在线训练可能需要使用浮点运算，这在内核执行中默认是禁用的。由于在内核中启用 FPU 会产生高开销，一个有前途的方法是依赖轻量级的学习模型，如基于整数的学习[^17^, ^23^, ^50^, ^51^]。作为另一种方法，ML 训练可以在用户空间中使用浮点运算实时进行，模型会定期被量化并推送到内核进行推理。</p>
<p>ML 推理。与学习不同，ML 推理必须在关键执行路径中执行，因此必须非常高效。整体性能提升将取决于推理开销和预测准确性之间的权衡。有一种成熟的工作方法依赖于知识蒸馏，将大型的“教师”模型转化为大幅度缩小的“学生”模型，而不会牺牲太多的准确性（例如，更简单的 NN 或甚至决策树）。蒸馏到可解释的模型（如决策树）也将阐明哪些特征是决策的关键，有助于实现“精简监控”的目标。特征重要性排名算法也对理解特征的权重有用。已经证明，为推理量化预训练模型具有良好的性能。根据内核子系统的不同，推理可以在 CPU 上本地执行，或者在独立或高速缓存一致的 GPU 上执行，如果从 GPU 到 GPU 的往返时间对该子系统来说是可以接受的。如果训练在用户空间进行，模型可以定期更新、量化并安装到内核。在适当的情况下，推理结果可以被缓存并在内核子系统中重复使用，而不会产生重复的查询。此外，RMT 程序验证器应在将它们接纳到内核之前推理 ML 模型的效率[^3^, ^32^]。按需模型压缩技术也可以根据指定的性能目标和资源约束来修剪模型，例如，作为可以从 RMT 验证器调用的后续步骤。</p>
<p>定制 ML。当现有的 ML 模型不能开箱即用时，我们还需要为每个子系统和任务确定定制的模型。在这个方向上，神经架构搜索（NAS）是一种给定某个数据样本时搜索适当的神经网络架构的方法。它可以使用 ML 构建块（例如，卷积层）为给定任务自动构建具有不同深度、宽度和超参数的 NN；这样的架构已经被证明在一系列任务上具有优越的性能[^15^, ^26^, ^34^, ^35^, ^46^, ^47^]。NAS 通常是一个耗时的操作，所以它在离线训练阶段进行。一旦确定并训练了一个好的神经网络架构，它就可以被安装到内核中进行推理。在不同的 RMT 表格中，将应用超参数优化技术来微调他们的模型，并使用元学习（或“学习学习”）技术来确定使用最佳的 ML 模型。作为 ML 定制的另一种形式，操作系统内核运行在各种硬件平台上（例如，不同的 ISA，独立的 vs. 高速缓存一致的 GPU，或专用的 ML 加速器）；我们应该根据底层平台调整或共同设计 ML 算法，并自动构建平台成本模型。</p>
<h1 id="4-初步验证"><a href="#4-初步验证" class="headerlink" title="4 初步验证"></a>4 初步验证</h1><p>我们将展示我们目前的进展。我们已经开发了一个内核 RMT 原型，它在 Linux 内核 v5.9.15 的指定挂钩点上进行硬编码，并对页面预取和 CPU 调度进行了两个案例研究。</p>
<p>案例研究 #1。Linux 页面预取器弥补了主内存和外部磁盘之间的速度差异。默认的 readahead 预取器检测顺序页面访问并预取下一组页面。最近的工作，Leap，已经扩展了这个功能，以便检测跨步模式。为了展示 ML 的优势，我们开发了一个内核整数决策树，可以捕获更复杂的访问模式。</p>
<p>我们的 RMT 管道为每个进程收集页面访问跟踪，用于在线训练和推理。它在每个时间窗口的后台周期性地训练一个新的决策树，同时丢弃旧的决策树。在预取时，另一个 RMT 表格查询 ML 模型以预测要获取的下一组页面。图 1 使用 OpenCV 视频调整应用程序和 Numpy 矩阵卷积程序[^12^, ^45^]，比较了我们的基础设施与 Linux 以及 Leap 的性能。结果显示，与 Linux 相比，ML 模型的准确性提高了 28%-80%，与 Leap 相比，提高了 23%-44%，大大缩短了作业完成时间。</p>
<p>案例研究 #2。Linux 完全公平调度器（CFS）周期性地将任务迁移到 CPU 以进行负载平衡，同时考虑一系列因素以避免性能退化。最近的一个项目显示，一个 MLP（多层感知器）ML 模型可以有效地模仿 Linux CFS 的决策。我们的下一个案例研究使用我们的基础设施来研究这个场景。</p>
<p>CFS 中的 can_migrate_task 函数调用 RMT 来查询 ML 模型，以预测是否应该迁移一个任务。我们首先使用我们的基础设施复制了中的实验，用于卸载训练具有量化模型。使用 Blackscholes 和 PARSEC 基准套件中的其他模型，以及矩阵乘法和 Fibonacci 计算程序，我们的基础设施在模仿 Linux CFS 决策方面达到了 99% 的预测准确性，与相似。接下来，我们使用 scikit-learn 工具箱来排名和识别负载平衡的两个关键特征（在中使用的 15 个特征中）。有了这个更精简的监控，我们的原型仍然达到了 94+% 的准确性；在作业完成时间方面，它取得了有竞争力的结果。表 2 比较了 ML 与 Linux CFS 启发式方法的性能。</p>
<h1 id="5-相关工作"><a href="#5-相关工作" class="headerlink" title="5 相关工作"></a>5 相关工作</h1><p>系统中的 ML。ML 已经在索引检索、布隆过滤器查询、CPU 调度、C++ 内存管理以及许多其他上下文中找到了应用。张和黄主张使用它来优化操作系统内核。DBOS 项目也提出建立一个数据中心的操作系统，其中的组件可以使用 ML 进行学习。我们的项目追求类似的目标，但它提出了一个具体的提案，基于 RMT 架构将 ML 集成到内核中。</p>
<p>操作系统专用化。操作系统专用化[^9^, ^19^]一直是社区的长期目标，最近，eBPF 受到了欢迎。在 Hypercallbacks 和 Hyperupcalls 中，虚拟机使用 eBPF 向超级管理员注入不受信任的代码以进行策略执行。另一方面，LBM 将保护程序注入到内核中，以防御恶意外设。也已经为 eBPF 程序 和它们的 JIT 编译器开发了验证技术，以确保注入代码的高度保证。我们的想法受到了 eBPF 基础设施的启发，但 RMT 程序增强了专用的 ML 指令集和 ML 模型，它们的验证器需要检查更高级的属性，超出了有界执行，例如 ML 模型性能和隐私目标。</p>
<h1 id="6-总结和未来工作"><a href="#6-总结和未来工作" class="headerlink" title="6 总结和未来工作"></a>6 总结和未来工作</h1><p>我们已经为一种基于 RMT 的新型可重配置内核数据路径架构进行了论证，该架构使操作系统内核中的机器学习变得高效，并提出了 RMT 程序设计、内核机器学习和程序安全检查的研究挑战。我们还展示了两个案例研究的一些初步结果。未来，还有很多工作要做。为不同的内核子系统定制 ML 技术，在 ML 开销和预测准确性之间找到一个好的平衡，何时以及如何调用像 GPU 这样的加速器，以及在内核中完全设计和实现 RMT，都是有趣的研究方向。总的来说，我们认为在内核中使用 ML 代表了设计空间中的一个有趣的点。类似于 SPIN 和 exokernel，这样的设计将考虑到应用程序的多样性和专用化的需要。然而，与其修改操作系统并允许应用程序控制策略决策，使用 ML 可能会导致更强大的内核策略，尽管应用程序存在差异。使用数据驱动的方法也有可能将内核优化放在比现在更坚实的基础上。</p>
</div>
<footer class="article-footer">
<a data-url="https://worstkid92.github.io/papers.github.io/2023/12/08/Toward-Reconfigurable-Kernel-Datapaths-with-Learned-Optimizations/" data-id="clqk8x19o0002akvaaa0c5sxa" data-title="Toward Reconfigurable Kernel Datapaths with Learned Optimizations" class="article-share-link"><span class="fa fa-share">Share</span></a>
</footer>
</div>
</article>
<article id="post-learned-operating-system" class="h-entry article article-type-post" itemprop="blogPost" itemscope itemtype="https://schema.org/BlogPosting">
<div class="article-meta">
<a href="/papers.github.io/2023/12/06/learned-operating-system/" class="article-date">
<time class="dt-published" datetime="2023-12-06T02:12:31.000Z" itemprop="datePublished">2023-12-06</time>
</a>
</div>
<div class="article-inner">
<header class="article-header">
<h1 itemprop="name">
<a class="p-name article-title" href="/papers.github.io/2023/12/06/learned-operating-system/">learned operating system</a>
</h1>
</header>
<div class="e-content article-entry" itemprop="articleBody">
<h1 id="Abstract"><a href="#Abstract" class="headerlink" title="Abstract"></a>Abstract</h1><p>操作系统是计算机系统的核心，数十年来，人们一直致力于操作系统的研究和工程开发。为了跟上现代硬件和应用的发展速度，我们认为在未来的操作系统开发中应采取不同的方法。我们不应完全依赖人类的智慧，而应利用人工智能和机器学习技术来自动 “学习 “如何构建和调整操作系统。本文探讨了 “学习 “操作系统方法的机遇和挑战，并就如何构建这样的操作系统向未来的研究人员和从业人员提出了建议。</p>
<h1 id="1-Introduction"><a href="#1-Introduction" class="headerlink" title="1 Introduction"></a>1 Introduction</h1><p>在所有类型的软件中，操作系统可能是最复杂、最错综复杂的类型。操作系统几乎是所有计算机系统的核心。它们管理硬件资源，为应用程序的执行提供受保护的环境。因此，操作系统的设计会影响在其上运行的所有应用程序。传统上，操作系统都是由专家通过长期、反复的工程设计构建而成。大多数操作系统（如 Linux 和 Windows）都采用通用设计，并在安装时或安装后留有各种调整选项。通常的做法是以默认配置安装操作系统，并在需要时更改特定配置。 这种构建和调整操作系统的长期做法有四个局限性。首先，操作系统发展缓慢，改变一个成熟的操作系统很难。然而，如今的硬件和应用程序变化很快。虽然新的硬件和应用可能不需要从头开始构建全新的操作系统，但重写或添加某些操作系统功能在很大程度上会使它们受益。遗憾的是，传统的手动操作系统开发方法无法跟上硬件和应用不断发展的步伐<br>其次，很难正确调整操作系统。现代操作系统有许多会影响应用程序性能的配置。例如，Linux v5.1（最新版本）的内核配置总数超过 17K。手工调整大量操作系统配置的过程既漫长又特别。此外，这样做也无法达到最佳效果。 第三，操作系统不会在运行时 “改变”。在构建、安装和配置操作系统后，其功能、策略和参数都保持不变。因此，当今的操作系统无法动态适应应用程序不断变化的行为和需求。<br>最后，通用操作系统无法很好地支持各类应用程序或硬件。当今主流操作系统的大多数功能都是为通用目的而设计的。 可配置参数仅允许对某些操作系统功能进行有限的专业化。例如，Linux 交换系统提供了一个名为 swappiness 的参数，用于控制交换内存页的频率，但它在选择交换页时总是使用 LRU 策略。此外，swappiness 是一个全局参数，在 Linux 操作系统上运行的所有应用程序都必须使用相同的 swappiness 值。随着未来硬件和应用程序的异构性越来越强，操作系统应允许更多的特殊化.<br>我们认为，这些局限性要求我们重新思考传统的操作系统架构。我们的答案是利用机器学习（ML）技术来构建和配置操作系统，我们称这种方法为 “学习型 “操作系统。例如，我们可以利用 ML 预测操作系统的最佳配置，这样的配置可以在运行时不断适应应用程序的变化。 人工智能还可用于生成某些操作系统功能的策略和机制。通过设计和构建框架，为操作系统训练和使用 ML 模型，我们可以避免操作系统开发过程中的大量工程工作。此外，基于 ML 的方法有可能产生更好的结果，对不同的应用具有更强的适应性和微调能力。 然而，”学习 “操作系统并非易事。之前有一些使用 ML 技术生成或改进（简单）操作系统策略的尝试，但都没有被大规模采用。尽管如此，随着最近将人工智能技术成功应用于数据库等底层软件，我们相信，学习型操作系统不仅是可行的，而且比目前利用启发式方法和人类经验构建的操作系统更高效。</p>
<h1 id="2-Opportunities-for-ML-in-OSes"><a href="#2-Opportunities-for-ML-in-OSes" class="headerlink" title="2 Opportunities for ML in OSes"></a>2 Opportunities for ML in OSes</h1><p>机器学习可以辅助或取代至少三种类型的传统操作系统组件。首先，机器学习可用于（动态）在操作系统中设置许多配置。其次，机器学习技术可用于根据应用程序行为和硬件属性在操作系统中生成策略。最后也是最积极的方法是使用机器学习来构建某些操作系统机制。</p>
<h2 id="2-1-学习配置"><a href="#2-1-学习配置" class="headerlink" title="2.1 学习配置"></a>2.1 学习配置</h2><p>现代操作系统包含数千种配置可以由特权用户在操作系统安装时或之后进行设置。例如，Linux-5.1 中的内存系统（“mm”）、文件系统（“fs”）和网络系统（“net”）有 89、351 和 729 种配置。 在所有类型的 Linux 中配置，至少有两大类可以直接影响应用程序的性能，并且可以在很大度上从机器学习方法中受益。首先，Linux中有很多与时序相关的配置，例如中断CPU核心的频率（对于线程调度），调用后台交换的频率（用于内存分页），刷新缓冲区缓存的频率（用于存储），以及CPU时钟频率的采样率（用于能源和性能）。 设置这些与时序相关的配置很困难，因为需要进行各种权衡。 例如CPU频繁中断提供了提高 CPU 利用率的机会（更多积极的线程调度），但可能会导致性能开销（通过抢占和上下文切换线程），这反过来，又会降低 CPU 的有效利用率。<br>其次，各种类型的配置有很多大小，例如缓冲区缓存大小（用于存储缓存）、磁盘预取量（用于存储访问）和交换预取数量（用于内存分页）。 设置这些与大小相关的配置很困难，特别是当需要权衡时不同的尺寸。 例如，更大的缓冲区高速缓存可以改善存储系统的性能，但降低了可用用户应用程序的内存。<br>上述两种类型的配置中的许多都会极大地影响应用程序性能和其他重要的配置能源成本等指标。 然而，设置它们的做法长期以来一直是一项涉及繁重的工程和人力的工作：通过启发式、反复试验或离线实验。 而且，一旦设定，就很少改变。<br>ML 更适合设置这些操作系统配置。使用过去的工作负载和操作系统/硬件环境训练的良好机器学习模型可能会优于人类设置的配置。该模型可以继续动态生成新的配置以适应工作负载和环境的变化。强化学习是一种很有前途的生成操作系统配置的机器学习技术。尽管强化学习的推理过程成本更高，但它很适合我们的需求，因为操作系统配置只需要很少重新生成。</p>
<h2 id="2-2-学习策略"><a href="#2-2-学习策略" class="headerlink" title="2.2 学习策略"></a>2.2 学习策略</h2><p>操作系统需要做出许多决定。这些决策通常会影响应用程序性能和资源利用率，但很少影响正确性。可以动态适应不同应用程序行为的机器学习技术有可能超越当前操作系统基于启发式的全局静态策略。下面，我们讨论可以通过机器学习生成的几种类型的操作系统策略。<br>空间分配。 操作系统管理硬件资源的一个关键任务是空间分配。 当应用程序请求内存或存储空间时，操作系统需要决定为应用程序提供哪些可用空间。 很多这些分配政策基于启发式和简单的算法。 例如Linux分配虚拟内存空间对于使用最适合策略的 mmap 系统调用（即，选择适合所请求的 mmap 的最小虚拟地址孔尺寸）。 Linux ext 系列文件系统分配近邻同一目录下的文件的空格。 尽管这些策略适用于许多工作负载和用途，但它们并不是唯一的选择。所有类型应用的最佳选择。 例如，文件同一目录下的文件很可能被一起访问，将它们放置得彼此靠近可以节省磁盘寻道。但是，当用户访问不同目录下的文件时，当前 ext 文件系统的分配策略不起作用。<br>为了更好地做出空间分配决策，操作系统可以使用用于预测分配候选位置的 ML 模型。构建良好的机器学习模型对于基于机器学习的空间分配的成功至关重要。 一个可行的方法是开始构建通过分析用户请求多少空间、什么空间的历史痕迹来建立模型（全局、每个用户或每个应用程序）<br>分配的操作系统、如何有效利用空间（即如何有很多碎片），以及用户如何访问分配的空间。 然而，静态模型还不够，因为应用程序行为可能会发生变化，并且可能会出现新类型的应用程序。 我们期待一些在线学习技巧将需要不断更新空间分配机器学习模型。<br>调度。 操作系统会做出多种类型的调度决策。 对于 CPU 调度，操作系统决定运行哪些线程在每个CPU核心上。 当一个正在运行的进程的时间片过期或进程放弃其运行核心时，Linux（自 v2.6.23 起）使用 CFS（完全公平调度）默认情况下，策略决定接下来运行哪个线程。 操作系统还<br>管理各种队列，例如网络队列和存储队列。他们在这些队列上安排请求/操作，以获得更好的性能、公平性和负载平衡。 设置好调度策略是困难的，好策略的标准可以不时改变。 例如，在 CFS 之前，较旧的Linux 中的版本使用 O(1) CPU 调度程序。不是手动调整调度策略，而是动态调整<br>使用机器学习生成的调度决策可以极大地提高操作系统的效率。 另外，与传统调度相比政策、机器学习模型有可能运行得更快并节省成本元数据存储空间。 例如Linux CFS调度器使用红黑树来存储可用的虚拟内存地址范围，需要 O(logN) 时间才能做出决定。<br>缓存管理。 缓存是一种广泛使用的技术操作系统。 操作系统虚拟内存系统将热数据存储在物理内存中内存并将其余部分保留在速度较慢的存储设备中。 文件系统使用内存缓冲区高速缓存来存储热文件数据和元数据。 管理缓存时，操作系统需要决定何时以及要驱逐哪些数据。 目前，操作系统使用一组固定的缓存驱逐策略，通常是多年的研究和工程工作结果. 例如，大多数操作系统虚拟内存系统尝试交换出以下内存页最近最少使用某种形式的近似 LRU。 这样的策略对于显示良好时间性的工作负载效果很好地方，但不适合那些地方不好或那些其局部性无法被近似 LRU 捕获<br>政策。<br>操作系统可以使用 ML 来代替像 LRU 这样的固定策略决定缓存驱逐的候选者。 这样的机器学习模型可以是一起学习使用过去的内存/存储访问模式与学习缓存大小（第 2.1 节）。 我们将讨论学习第 3.1 节中相关目标的挑战。</p>
<h2 id="2-3-学习机制"><a href="#2-3-学习机制" class="headerlink" title="2.3 学习机制"></a>2.3 学习机制</h2><p>大多数配置和策略并不影响操作系统的正确性，因此机器学习是它们的良好候选者。更具挑战性的任务是使用机器学习进行需要精确的操作系统任务。在操作系统中有许多这样的任务，它们通常是实现某些功能的机制。<br>受到学习索引的启发，我们确定了两种可以用机器学习模型替换的操作系统中的“机制”，它们都执行将一种抽象映射到另一种抽象的功能。第一个是从虚拟内存地址映射到物理内存地址，目前由页表执行。第二个是从文件名和偏移量映射到磁盘逻辑块地址，目前由文件系统多级索引结构完成。这两种类型的“映射表”对所有内存和存储系统的性能至关重要，已经投入了大量的研究和工程努力来改进它们。<br>内存和文件映射都可以从机器学习方法中受益。机器学习模型有可能降低内存和文件映射的性能和空间成本。此外，机器学习模型是灵活的，可以定制到任何类型的工作负载。与今天的内存系统中的固定大小的内存页不同，基于机器学习的映射可以推断任何大小和偏移的内存空间。此外，机器学习模型可能比多级页表更小，运行速度更快。我们可以通过将模型参数存储在连续的内存空间中来进一步提高其性能，以提高空间局部性和CPU缓存命中率。</p>
<h1 id="3挑战和潜在解决方方案"><a href="#3挑战和潜在解决方方案" class="headerlink" title="3挑战和潜在解决方方案"></a>3挑战和潜在解决方方案</h1><h2 id="3-1-Model-Building"><a href="#3-1-Model-Building" class="headerlink" title="3.1 Model Building"></a>3.1 Model Building</h2><p>第二部分我们分析了操作系统的哪一部分可以从机器学习中受益，即什么可以被学习。接下来的步骤是设计一个学习方法。在许多机器学习应用中，机器学习模型选择是一个困难的问题。虽然像AutoML这样的系统可以在很大程度上自动化机器学习模型的选择，但它们只适用于像图像识别和自然语言处理这样的研究得比较透彻的问题。在为操作系统选择合适的模型时，有许多独特的挑战。<br>首先，我们如何判断一个模型的好坏呢？一个看似直接的方法是评估在应用了一个模型后，应用程序的性能变化。然而，应用程序的性能可能会受到许多因素的影响，比如工作负载的变化，同一操作系统上运行的其他工作负载，以及操作系统的其他部分。为了更好地确定某个模型的效果，我们应该寻求更好、更局部化的评估目标。例如，我们可以使用缓冲区缓存未命中率来确定预测缓冲区缓存替换策略的模型的好处，而不是应用程序的性能。<br>接下来，我们应该构建全局的机器学习模型，每个用户的模型，还是每个应用程序的模型呢？更细粒度的模型可以通过更多的定制和专业化实现更准确的预测，但需要更多的资源（例如，内存空间，用于训练的CPU时间）。<br>在预测过程中的另一个潜在优化是生成多个候选项或预测未来的多个步骤。例如，分页驱逐模型可以返回前K个驱逐的候选项，操作系统只需要在K个页面驱逐中进行一次推理。这样做可以减少在每一步生成单个候选项的性能开销。<br>最后一个主要的挑战是在操作系统中学习多个相关的任务。不同的配置、策略和机制都可以影响操作系统子系统的性能，有时它们甚至可以相互关联。例如，缓冲区缓存的大小、刷新频率和驱逐策略都可以影响缓冲区缓存的性能（从而影响存储系统的性能）。缓冲区缓存的大小也可以影响内存系统的性能。因此，我们应该联合优化相关任务以获得最佳结果。我们设想在这种情况下，多任务学习会很有帮助。</p>
<h2 id="3-2-training"><a href="#3-2-training" class="headerlink" title="3.2 training"></a>3.2 training</h2><p>对于操作系统来说，训练机器学习模型面临着独特的挑战。<br>首先，收集训练数据应该对前台应用程序造成最小的开销。例如，追踪每次内存访问以构建预测内存驱逐候选项的模型是不可行的。大量的训练数据也会导致过高的空间开销。另一方面，没有足够的训练数据可能会降低机器学习模型的准确性。一种可能的解决方案是使用预先收集的、代表性好的训练数据进行离线训练，然后使用在线训练（不频繁地）更新构建的模型。离线训练可以使用更细粒度的数据，而在线训练，我们可能只能收集粗粒度的数据，以免干扰前台应用程序的性能。<br>其次，我们如何构建验证集？对于某些问题，存在基本事实或理论最优解。例如，对于CPU调度，理论上最好先运行剩余时间最短的作业（以获得最快的周转时间）；对于页面替换，理论上最好的是驱逐最远未来不会被使用的页面。这些理论上最好的解决方案可以直接用作训练期间的验证集。然而，对于其他问题，没有明确的最佳解决方案。一种可能的方法是让用户通过提供奖励函数来定义他们的应用程序的需求或目标，而不是提供一个验证集。操作系统可以使用强化学习技术来找到满足这些需求/目标的最佳解决方案。</p>
<h2 id="3-2-推理"><a href="#3-2-推理" class="headerlink" title="3.2 推理"></a>3.2 推理</h2><p>不同的操作系统学习目标对推理速度有不同的标准。第一类学习只需要偶尔运行一次或在工作负载变化时运行，即前台应用程序操作不需要等待这些推理结果。配置和策略都属于这一类别。对于这种类型，推理可以运行得稍微慢一些，这样我们就可以探索更昂贵的机器学习技术，如强化学习。<br>操作系统的第二类“决策”必须非常快，因为它们在应用程序性能关键路径上。例如，操作系统需要在线程开始执行之前决定在一个核心上调度哪个线程，这意味着决策的紧密界限应该在上下文切换的时间内或者最多在上下文切换的时间附近。有了快速的存储和网络设备，操作系统文件/存储和网络系统中的决策也需要快速做出（大约或在1微秒内）。GPU和其他专用处理器（如TPU）可以使用复杂的模型进行快速预测，但是调用它们仍然需要很长时间（使用今天的PCIe需要1-2微秒）。为了能够为这些操作系统用途快速地进行推理，我们要么需要减少这种调用成本，要么需要减少模型复杂性并在本地CPU上运行。<br>除了执行推理的性能开销外，还有存储用于推理的机器学习模型的内存空间开销。大型模型可以轻易地占用数百MB的内存。当操作系统中有数百到数千个配置、策略和机制需要学习时，模型空间成本可能会过高。一种有前景的方法是利用循环神经网络中的模型内存重用技术来减少内存消耗。</p>
<h2 id="3-4-在操作系统中集成机器学习"><a href="#3-4-在操作系统中集成机器学习" class="headerlink" title="3.4 在操作系统中集成机器学习"></a>3.4 在操作系统中集成机器学习</h2><p>单独的机器学习不能构成一个完整的操作系统。我们预见到在现有的操作系统中集成机器学习模型及其预测会有几个挑战。<br>首先，虽然大多数操作系统策略只用于性能提升，可能是次优的或者“错误的”，但是一些操作系统功能，如文件系统和虚拟内存映射，需要精确。如何使用本质上是概率性的机器学习技术来实现操作系统的确定性任务，是一个有趣但具有挑战性的问题。一种可行的方法是让机器学习模型首先做出一系列的概率预测，然后使用传统算法在这个范围内计算最终的精确答案。机器学习预测的范围越精确，精确搜索的第二步就越快。<br>除了正确性保证，如何在内核空间运行机器学习模型也是一个新的挑战。与用户空间不同，内核空间缺乏机器学习库的支持。为了让内核使用机器学习技术，可能的选择在于构建新的内核空间机器学习库和在用户空间运行机器学习，然后将结果传回到内核空间。第一种选择需要大量的工程工作，而后一种选择可能会因为上下文切换而导致性能损失。<br>最后，像Linux这样的现代操作系统采取了单一内核的方法，并且在几十年的开发工作中变得非常复杂。在现有的操作系统中集成机器学习将需要精心的工程设计，以最小化对操作系统其余部分的干扰。</p>
<h2 id="3-5-安全性"><a href="#3-5-安全性" class="headerlink" title="3.5 安全性"></a>3.5 安全性</h2><p>操作系统应该为应用程序提供对硬件资源的保护访问。使用学习的操作系统方法，使用应用程序数据学习的机器学习模型在操作系统中使用是否安全呢？尽管我们设想所有与安全和保护相关的任务在操作系统中仍然以传统的方式实现，但是在操作系统内核的其余部分使用机器学习可以引入独特的安全威胁和影响。<br>当在操作系统中应用机器学习技术时，用户数据将间接地参与到操作系统的控制平面中。如果没有适当的保护，恶意用户将能够通过提供精心制作的数据来操纵训练和推理过程。这样做可能会导致操作系统使用错误的机器学习模型，这些模型对攻击者有利。例如，攻击者可以训练一个机器学习模型，使其总是驱逐其他应用程序的内存，并发起拒绝服务攻击。它还可以生成一个糟糕的机器学习模型，导致操作系统不断地预测失误，性能下降。对不同的应用程序使用不同的机器学习模型（即机器学习的隔离）可以大大提高学习操作系统的安全性。然而，保护免受侧信道攻击和防止信息泄露仍然是一项挑战。</p>
<h1 id="4-相关工作"><a href="#4-相关工作" class="headerlink" title="4 相关工作"></a>4 相关工作</h1><p>针对其他低级系统的机器学习。最近的学习索引工作提出了用预测数据位置的神经网络模型替换传统的基于树的索引结构。学习索引启发了许多后续的研究工作。事实上，这篇论文也受到了它的启发。学习索引的后续工作是SageDB，一个学习数据库系统。除了索引，它还使用机器学习进行合并和哈希连接操作。学习索引的另一个扩展是学习布隆过滤器。还有许多提议使用机器学习来解决各种硬件问题。更相关的是一项最近的工作，该工作使用循环神经网络（RNN）预测内存访问模式并执行内存预取。<br>针对操作系统的机器学习。尽管机器学习已经在许多领域中使用，最近在低级系统中的使用也更多，但操作系统很少采用任何机器学习技术，大多数研究提议都可以追溯到几十年前。例如，有几个提议使用机器学习技术（例如C4.5决策树，线性回归）来改善应用程序作业的平均周转时间，例如，通过调整内核抢占时间和通过预测作业运行时间。Lynx是一个使用机器学习更好地执行SSD预取的系统。它利用马尔可夫链来检测I/O工作负载模式并计算文件页之间的转移概率。</p>
<h1 id="5-结论"><a href="#5-结论" class="headerlink" title="5 结论"></a>5 结论</h1><p>机器学习技术的进步以及“大数据”和计算资源的可用性使得我们可以在许多以前依赖人力的领域应用机器学习。我们相信操作系统也是这样一个领域。本文系统地探讨了在操作系统中使用机器学习的机会和挑战。这当然只是构建真正的学习操作系统解决方案的起点。我们预期会出现更多的设计、开发和部署挑战。然而，我们相信学习操作系统是一个值得探索的方向，希望本文能激发和帮助未来在这个领域的研究者和从业者。</p>
<h1 id="6-读后感"><a href="#6-读后感" class="headerlink" title="6 读后感"></a>6 读后感</h1><p> policy：是后果最小的，它的<br> configuration：学习成本很高。UNIKRAFT 0.15目前的配置项在百数量级，跟linux中的一个子系统的配置项数量相当。<br> mechenism就文中的例子来说收益可能是最高的，但是 </p>
<h1 id="7-related："><a href="#7-related：" class="headerlink" title="7 related："></a>7 related：</h1><p> Toward reconfigurable kernel datapaths with learned optimizations HOS21<br> 在这篇论文中，作者们提出了一种可重配置的内核数据路径的概念。在这种架构中，优化是通过使用机器学习从经验数据中计算出来的，并通过内核虚拟机以安全和系统化的方式集成到内核中。这个虚拟机实现了可重配置匹配表（RMT）的抽象，其中表格被安装到内核中，当性能关键事件发生时，匹配查找当前的执行上下文，动作编码由ML计算出的特定于上下文的优化，这些优化可能会因应用程序而异。它做了试验是Page prefetching和Scheduler<br> Operating Systems for Resource-adaptive Intelligent Software: Challenges and Opportunities<br>在这篇论文中，作者们提出了一种新的操作系统抽象，即ServiceOS，用于未来的资源自适应智能软件系统。ServiceOS的理念受到了由服务导向架构（SOA）支持的“软件即服务”交付模型的启发。ServiceOS的关键原则基于资源解耦，资源作为服务的提供，以及基于学习的资源调度和分配。<br>他们设想的架构将支持离线和在线学习算法，以及各种内核子系统。RMT验证器将在允许RMT程序进入内核之前检查程序的良构性和模型效率。一个被接纳的程序可以被解释为字节码或即时编译以优化内核数据路径。<br>“Machine Learning for Load Balancing in the Linux Kernel”是一篇由Jingde Chen、Subho S. Banerjee、Zbigniew T. Kalbarczyk和Ravishankar K. Iyer共同撰写的论文。这篇论文探讨了如何将机器学习（ML）集成到Linux内核中，以实现动态的负载均衡。<br>在这篇论文中，作者们提出了一种新的方法，即通过模仿学习将机器学习应用到Linux CFS负载均衡器的一部分。他们使用eBPF和kprobes对内核函数进行动态跟踪，用于系统的运行时数据收集。然后，他们训练了一个基于多层感知器（MLP）模型，该模型根据收集的训练数据模仿CFS负载均衡器。</p>
</div>
<footer class="article-footer">
<a data-url="https://worstkid92.github.io/papers.github.io/2023/12/06/learned-operating-system/" data-id="clptnqbqt0001cova6qk47tv5" data-title="learned operating system" class="article-share-link"><span class="fa fa-share">Share</span></a>
</footer>
</div>
</article>
<article id="post-DoOSAbstractionsMakeSenseOnFPGA" class="h-entry article article-type-post" itemprop="blogPost" itemscope itemtype="https://schema.org/BlogPosting">
<div class="article-meta">
<a href="/papers.github.io/2023/12/05/DoOSAbstractionsMakeSenseOnFPGA/" class="article-date">
<time class="dt-published" datetime="2023-12-05T01:28:57.000Z" itemprop="datePublished">2023-12-05</time>
</a>
</div>
<div class="article-inner">
<header class="article-header">
<h1 itemprop="name">
<a class="p-name article-title" href="/papers.github.io/2023/12/05/DoOSAbstractionsMakeSenseOnFPGA/">OSDI20:Do OS Abstractions Make Sense On FPGA</a>
</h1>
</header>
<div class="e-content article-entry" itemprop="articleBody">
<h1 id="Abstraction"><a href="#Abstraction" class="headerlink" title="Abstraction"></a>Abstraction</h1><p>这篇论文主要探讨了在混合计算系统中，尤其是作为混合系统一部分的FPGA，传统的操作系统抽象在何种程度上是有意义的。混合计算系统由CPU服务器和用于应用加速的现场可编程门阵列（FPGA）组成，现在已经在数据中心和云中普遍存在。FPGA可以为一系列工作负载带来巨大的性能和能效改进，但是FPGA基础应用的开发和部署仍然很麻烦，这导致了最近的一些工作，它们在FPGA上复制了传统操作系统执行环境的子集（如虚拟内存，进程等）<br>为了回答这个问题，他们构建并评估了Coyote，这是一个为FPGA提供完整的操作系统抽象的开源、可移植、可配置的“shell”，并与主机操作系统一起工作。Coyote支持在租户之间对FPGA进行安全的空间和时间复用，虚拟内存，通信和内存管理都在一个统一的执行环境中。Coyote的开销很小，性能优势显著，但更重要的是，它让我们能够反思将操作系统抽象整体导入到FPGA是否是最好的前进方式。。</p>
<h1 id="1-Intro"><a href="#1-Intro" class="headerlink" title="1.Intro"></a>1.Intro</h1><p>现场可编程门阵列 (FPGA) 现已成为数据中心和云提供商的标准配置 [1, 3, 12]，与 ASIC 或 GPU 相比，它以更低的功耗为许多应用提供了更大的灵活性.尽管（由于其在嵌入式系统和原型设计方面的传统）仍然难以编程、部署和安全管理。因此，随着大量研究使 FPGA 更易于编程 ，最近的大量工作将操作系统设计和实现的思想应用到资源分配、共享、隔离和管理以 FPGA 为中心的计算机。<br>到目前为止，这项工作是零碎的，专注于功能的特定方面，例如Feniks 的目标是 FPGA 访问外设，Optimus通过地址转换等提供对主机虚拟内存的访问。这些都比现有技术产生了实质性的增量改进。与此同时，良好的操作系统设计之所以如此具有挑战性，是因为内核中所有功能之间的密切交互。不支持多个应用程序（多租户）或它们之间的强隔离的虚拟内存的用途有限。在不提供虚拟寻址和创建抽象硬件的通用执行环境的情况下虚拟化硬件设备，大部分问题都没有得到解决。无法利用动态重新配置芯片部件的能力的 FPGA 调度器的保质期有限，等等。因此，我们退一步问一个问题：传统操作系统概念（进程、虚拟内存等）在多大程度上可以（或应该）有效地转化为 FPGA？当他们出现时会发生什么？为了回答这个问题，我们需要采用全面、整体的方法并考虑完整的功能，而不是拘泥于操作系统的特定方面或仅支持有限的 FPGA 功能。<br>为此，我们构建了 Coyote，将一套连贯的操作系统抽象组合到一个统一的运行时中，用于基于 FPGA 的应用。像微内核一样，Coyote 提供了一套核心的基本功能，其他服务可基于这些功能：统一的执行环境和可移植性层、虚拟内存、物理内存管理、通信、空间和时间调度、网络，以及用户逻辑的软件进程或任务模拟。它以最小的开销（不到商用 FPGA 的 15%）实现了这些目标。 因此，我们在本文中的贡献如下：</p>
<ol>
<li>对于一系列操作系统抽象，在与其他操作系统交互的背景下，对每个操作系统如何映射到 FPGA 进行关键评估。</li>
<li>在 Coyote 中实现完整的集成，Coyote 是一种用于混合的可配置 FPGA“操作系统”计算服务器。</li>
<li>使用微基准和 5 个实际应用对 Coyote 进行定量评估。 </li>
<li>定性讨论这项工作对未来 FPGA 和操作系统设计的影响。<br>我们从任何 FPGA 操作系统都必须处理的基本硬件入手。这决定了 Coyote 的高层结构。</li>
</ol>
<h1 id="2-Foundation"><a href="#2-Foundation" class="headerlink" title="2.Foundation"></a>2.Foundation</h1><p>Coyote 以混合系统为目标，通过 PCIe、CXL 、CCIX或 OpenCAPI等外设总线将传统 CPU 与 FPGA 结合在一起，或采用英特尔 HARP或 ETH Enzian等本地一致性协议。如今，Coyote 可在装有 Xilinx VCU118、Alveo U250 [59] 和 Alveo U280 卡的 PC 上运行。向 Enzian 移植的工作正在进行中。我们避免任何可能妨碍使用现代 FPGA 功能（如多个区域的动态部分重新配置）或有用的 “硬 “片上功能的设计决策。 这就自然而然地将任何设计分割为在 FPGA 上运行的 “硬件 “组件和在主机 CPU 上作为操作系统和支持库的一部分运行的软件组件。 此外，FPGA 的动态重新配置将硬件组件进一步分割为 “静态区域 “和 “动态区域”，前者在启动时配置，后者包含子区域（vFPGA），每个子区域都可以即时更改。在所有 FPGA 数据中心部署中都存在这种分割（通常是简化形式）。在区域内和区域间，硬件组件通过 AXI等标准互连进行交互。<br>后面根据静态/动态/软件来介绍。</p>
<h2 id="2-1静态区域"><a href="#2-1静态区域" class="headerlink" title="2.1静态区域"></a>2.1静态区域</h2>
</div>
<footer class="article-footer">
<a data-url="https://worstkid92.github.io/papers.github.io/2023/12/05/DoOSAbstractionsMakeSenseOnFPGA/" data-id="clprq3znk00001kvahmuwajyz" data-title="OSDI20:Do OS Abstractions Make Sense On FPGA" class="article-share-link"><span class="fa fa-share">Share</span></a>
<ul class="article-tag-list" itemprop="keywords"><li class="article-tag-list-item"><a class="article-tag-list-link" href="/papers.github.io/tags/FPGA/" rel="tag">FPGA</a></li></ul>
</footer>
</div>
</article>
<article id="post-flexos" class="h-entry article article-type-post" itemprop="blogPost" itemscope itemtype="https://schema.org/BlogPosting">
<div class="article-meta">
<a href="/papers.github.io/2023/12/04/flexos/" class="article-date">
<time class="dt-published" datetime="2023-12-04T01:17:43.000Z" itemprop="datePublished">2023-12-04</time>
</a>
</div>
<div class="article-inner">
<header class="article-header">
<h1 itemprop="name">
<a class="p-name article-title" href="/papers.github.io/2023/12/04/flexos/">ASPLOS'22:FlexOS:Towards Flexible OS Isolation</a>
</h1>
</header>
<div class="e-content article-entry" itemprop="articleBody">
<h2 id="Abstact"><a href="#Abstact" class="headerlink" title="Abstact"></a>Abstact</h2><p>在设计时，现代操作系统被锁定在特定的安全和隔离策略中，该策略混合了一个或多个硬件/软件保护机制 (例如用户/内核分离); 在部署后重新审视这些选择需要大量的重构工作。当推出新的硬件隔离机制时，或者当现有的硬件隔离机制中断时，考虑到各种各样的现代应用程序的安全/性能要求，这种严格的方法显示了其局限性。<br>FlexOS，这是一种新颖的操作系统，允许用户在编译/部署时间而不是设计时间轻松地专门化操作系统的安全和隔离策略。这种模块化的LibOS是由不同粒度的组件组成。这些组件可以通过一系列硬件保护机制与各种数据共享策略和额外的软件强化进行隔离。操作系统采用探索技术，可帮助用户导航其解锁的广阔安全/性能设计空间。我们实现了该系统的原型，并针对多个应用程序 (Redis/Nginx/SQLite) 演示了flexos的广阔配置空间以及探索技术的效率:我们评估了80个Redis的FlexOS配置，并展示了在给定的性能预算下，如何将该空间概率地子集为5个最安全的空间。我们还表明，在等效配置下，FlexOS的性能与使用固定安全配置的现有解决方案相似或更好。<br>从摘要看出，这篇文章需要在大量的配置空间中寻找最安全的libs配置</p>
<h2 id="1-Intro"><a href="#1-Intro" class="headerlink" title="1.Intro"></a>1.Intro</h2><p>论文贡献如下：</p>
<p>使用FlexOS，用户可以在构建时决定应将哪些细粒度的OS组件放置在哪个隔室 (例如调度程序，tcp/ip堆栈等) 中，如何为每个隔室实例化隔离和保护原语，使用哪些数据共享策略进行隔室之间的通信，以及应该在哪些隔室上应用什么软件强化机制。为此，FlexOS抽象了在通用API后面划分任意软件时所需的通用操作，该通用API用于将现有的libo改造为FlexOS。（即库的整合）<br>由于这种库的编排存在大量的组合空间，FlexOS还提出一种partial safety ordering技术，在给定性能要求下实现最优资源配置。<br>作者希望在微内核空间的绝对安全（但性能低）和完全信任应用的单地址空间操作系统（安全性差）中找到平衡。</p>
<p>实验层面：<br>FlexOS支持 Intel MPK和 VM/EPT级别的隔离，以及广泛的加固机制（CFI（Control-Flow Integrity），ASAN（address sanitization，地址净化技术，用以避免一些潜在的地址泄漏问题））<br>使用四个流行应用程序进行的评估展示了FlexOS解锁的广泛安全性与性能权衡空间: 我们评估了Redis和Nginx的160多个配置。<br>证明了在等效配置下，FlexOS的性能更好或类似于基线/竞争对手: 整体内核，SASOS（Single-Address-Space OS），微内核和分隔的libos。</p>
<h2 id="2-Flexible-Isolation-Principles-and-Challenges"><a href="#2-Flexible-Isolation-Principles-and-Challenges" class="headerlink" title="2. Flexible Isolation: Principles and Challenges"></a>2. Flexible Isolation: Principles and Challenges</h2><h3 id="2-1-Principles"><a href="#2-1-Principles" class="headerlink" title="2.1 Principles"></a>2.1 Principles</h3><p>(P1) Flexos组件的隔离粒度应该是可配置的。分隔策略，即隔室的数量以及哪些组件被合并/拆分为隔室，对安全性和性能有重大影响，因此它应该是可配置的。</p>
<p>(P2) 所使用的硬件隔离机制应该是可配置的。存在广泛的隔离机制，具有各种安全性和性能影响。这些应该由用户配置。对于OS开发人员而言，支持新机制不应涉及任何重写/重新设计，而应与实现定义明确的API一样简单。</p>
<p>(P3) 软件硬化和隔离机制应该是可配置的。诸如CFI或软件故障隔离 (SFI) 之类的软件强化技术，以及诸如Rust之类的内存安全语言，以可变的性能成本带来了不同级别的安全性。它们应该选择性地适用于在给定用例中它们最有意义的组件。</p>
<p>(P4) 灵活性不应该以性能为代价。OS运行时性能应类似于在没有灵活性方法的情况下使用任何特定的安全配置所实现的性能。</p>
<p>(P5) 与现有软件的兼容性不应以很高的移植成本来最大程度地采用。</p>
<p>(P6) 应在FlexOS启用的广阔设计空间中引导用户。鉴于其非常大的配置空间，该系统应配备工具，可帮助用户针对给定的用例识别合适的安全/性能配置。</p>
<h3 id="2-2-Challenges-and-Approach"><a href="#2-2-Challenges-and-Approach" class="headerlink" title="2.2 Challenges and Approach"></a>2.2 Challenges and Approach</h3><p>P1和P4是考虑在隔离上平衡性能和通用性的问题，通过Unikraft，再加代码转译来实现。（参考文献主要是libOS相关）<br>P2和P5是考虑如何在现有系统中引入多种硬件隔离机制，同时降低引入成本。这里引入原文来解释一下：<br>技术不可知论在userland软件中已经很困难，但是核心内核设施 (中断处理，内存管理，调度) 引入了额外的复杂性，根据底层隔离技术的不同，这些复杂性应该被非常不同地处理。例如，某些技术在保护域之间共享单个地址空间 (例如MPK [15])，而其他技术则使用不相交的地址空间 (例如TEEs [3]，EPT)。FlexOS的主要思想是抽象现有的隔离技术，并根据技术确定需要不同处理的内核设施，并设计这些子系统，以最大程度地减少实现新技术时所需的更改。</p>
<p>P5同时要求减少移植工作量要求。FlexOS应该是扩充了Unikraft的可视化界面（参考工作是安全、性能相关的进程隔离ATC</p>
</div>
<footer class="article-footer">
<a data-url="https://worstkid92.github.io/papers.github.io/2023/12/04/flexos/" data-id="clprn9wwu0000akvagiivbfns" data-title="ASPLOS'22:FlexOS:Towards Flexible OS Isolation" class="article-share-link"><span class="fa fa-share">Share</span></a>
<ul class="article-tag-list" itemprop="keywords"><li class="article-tag-list-item"><a class="article-tag-list-link" href="/papers.github.io/tags/unikraft-security/" rel="tag">unikraft,security</a></li></ul>
</footer>
</div>
</article>
<nav id="page-nav">
<span class="page-number current">1</span><a class="page-number" href="/papers.github.io/page/2/">2</a><a class="extend next" rel="next" href="/papers.github.io/page/2/">Next »</a>
</nav>
</section>
<aside id="sidebar">
<div class="widget-wrap">
<h3 class="widget-title">Tags</h3>
<div class="widget">
<ul class="tag-list" itemprop="keywords"><li class="tag-list-item"><a class="tag-list-link" href="/papers.github.io/tags/FPGA/" rel="tag">FPGA</a></li><li class="tag-list-item"><a class="tag-list-link" href="/papers.github.io/tags/libos-security/" rel="tag">libos,security</a></li><li class="tag-list-item"><a class="tag-list-link" href="/papers.github.io/tags/unikraft-security/" rel="tag">unikraft,security</a></li></ul>
</div>
</div>
<div class="widget-wrap">
<h3 class="widget-title">Tag Cloud</h3>
<div class="widget tagcloud">
<a href="/papers.github.io/tags/FPGA/" style="font-size: 10px;">FPGA</a> <a href="/papers.github.io/tags/libos-security/" style="font-size: 10px;">libos,security</a> <a href="/papers.github.io/tags/unikraft-security/" style="font-size: 10px;">unikraft,security</a>
</div>
</div>
<div class="widget-wrap">
<h3 class="widget-title">Archives</h3>
<div class="widget">
<ul class="archive-list"><li class="archive-list-item"><a class="archive-list-link" href="/papers.github.io/archives/2024/02/">February 2024</a></li><li class="archive-list-item"><a class="archive-list-link" href="/papers.github.io/archives/2024/01/">January 2024</a></li><li class="archive-list-item"><a class="archive-list-link" href="/papers.github.io/archives/2023/12/">December 2023</a></li><li class="archive-list-item"><a class="archive-list-link" href="/papers.github.io/archives/2023/11/">November 2023</a></li></ul>
</div>
</div>
<div class="widget-wrap">
<h3 class="widget-title">Recent Posts</h3>
<div class="widget">
<ul>
<li>
<a href="/papers.github.io/2024/02/07/Deep-Learning-Focus/">Deep Learning Focus</a>
</li>
<li>
<a href="/papers.github.io/2024/01/30/Code-Generation-Using-Machine-Learning-A-Systematic-Review/">Code Generation Using Machine Learning: A Systematic Review</a>
</li>
<li>
<a href="/papers.github.io/2024/01/08/GPU-Acceleration-in-Unikernels-Using-Cricket-GPU-Virtualization/">GPU Acceleration in Unikernels Using Cricket GPU Virtualization</a>
</li>
<li>
<a href="/papers.github.io/2024/01/08/Loupe-Driving-the-Development-of-OS-Compatibility-Layers/">Loupe: Driving the Development of OS Compatibility Layers</a>
</li>
<li>
<a href="/papers.github.io/2023/12/21/reading-list/">reading list</a>
</li>
</ul>
</div>
</div>
</aside>
</div>
<footer id="footer">
<div class="outer">
<div id="footer-info" class="inner">
© 2024 John Doe<br>
Powered by <a href="https://hexo.io/" target="_blank">Hexo</a>
</div>
</div>
</footer>
</div>
<nav id="mobile-nav">
<a href="/papers.github.io/" class="mobile-nav-link">Home</a>
<a href="/papers.github.io/archives" class="mobile-nav-link">Archives</a>
</nav>
<script src="/papers.github.io/js/jquery-3.6.4.min.js"></script>
<script src="/papers.github.io/fancybox/jquery.fancybox.min.js"></script>
<script src="/papers.github.io/js/script.js"></script>
</div>
</body>
</html>