Download “Learned” Operating Systems and more Slides Operating Systems in PDF only on Docsity!
“Learned” Operating Systems
Yiying Zhang, Yutong Huang Purdue University
Abstract
With operating systems being at the core of computer sys- tems, decades of research and engineering efforts have been put into the development of OSes. To keep pace with the speed of modern hardware and application evolvement, we argue that a different approach should be taken in future OS development. Instead of relying solely on human wisdom, we should also leverage AI and machine learning techniques to automatically “learn” how to build and tune an OS. This paper explores the opportunities and challenges of the “learned” OS approach and makes recommendation for future researchers and practitioners on building such an OS.
1 Introduction
Among all types of software, operating systems are probably the most complex and intricate type. OSes are at the core of almost every computer system. They manage hardware resources and provide a protected environment for application execution. The design of an OS can thus affect all applications running on it. Traditionally, OSes are built by experts with long and recurring engineering efforts. Most OSes like Linux and Windows adopt general-purpose designs and leave vari- ous tuning options at or after installation time. The common practice is to install OSes with their default configurations and change specific configurations when needed. There are four limitations with this long-standing practice of building and tuning OSes. First, OSes have evolved slowly and changing a mature OS is hard. However, today’s hardware and applications change fast. Although new hardware and ap- plications may not require building a whole new OS from scratch, they can largely benefit from rewriting or adding cer- tain OS functionalities [ 6 , 14 ]. Unfortunately, the traditional manual OS development approach cannot keep up with the pace of evolving hardware and applications. Second, it is hard to properly tune an OS. Modern OSes have many configurations that can affect application perfor- mance. For example, Linux v5.1 (the latest version) has more than 17K kernel configurations in total. The process of hand- tuning the large number of OS configurations is lengthy and ad hoc. Moreover, doing so cannot achieve the best results. Third, OSes do not “change” at runtime. After building, installing, and configuring an OS, its functionalities, policies, and parameters all stay the same. As a result, today’s OSes cannot dynamically adapt to applications’ changing behavior and needs.
Finally, general-purpose OSes cannot support various types of applications or hardware well. Most functionalities in to- day’s mainstream OSes are designed for general purposes. Configurable parameters only allow limited specialization in certain OS functionalities. For example, the Linux swap system offers a parameter called swappiness to control the frequency of swapping out memory pages, but it always uses the LRU policy when choosing pages to swap out. More- over, swappiness is a global parameter and all applications running on a Linux OS have to use the same swappiness value. With growing heterogeneity in future hardware and applications [ 2 , 4 , 5 , 8 , 10 , 18 ], OSes should allow more spe- cializations. We believe that these limitations call for a rethink of tradi- tional OS architectures. Our answer is to leverage machine learning (ML) techniques to build and configure OSes, an ap- proach we call “learned” OSes. For example, we can use ML to predict the best configurations of an OS and such configu- rations can keep adapting to application changes at runtime. ML can also be used to generate policies and mechanisms of certain OS functionalities. By designing and building the framework to train and use ML models for OSes, we can avoid the huge engineering efforts of OS development. Moreover, ML-based approaches can potentially yield better results that are more adaptive and more fine-tuned to different applica- tions. However, “learning” OSes is not easy. There have been a handful of prior attempts in using ML techniques to generate or improve (simple) OS policies [ 16 , 19 ], but none of them have been adopted at production scale. Nevertheless, with the recent success of applying ML techniques to low-level software like databases [ 11 , 12 ], we believe that learned OSes are not only feasible, but also more efficient than current OSes which are built with heuristics and human experiences.
2 Opportunities for ML in OSes
ML can assist or replace at least three types of traditional OS components. First, ML can be used to (dynamically) set many configurations in an OS. Second, ML techniques can be applied to generate policies in an OS based on applica- tion behavior and hardware properties. The final and the most aggressive approach is to use ML to build certain OS mecha- nisms.
2.1 Learning Configurations
Modern OSes incorporate thousands of configurations that can be set by privileged users at or after OS installation time. For example, there are 89, 351, and 729 configurations for the memory system (“mm”), file systems (“fs”), and network- ing system (“net”) in Linux-5.1. Among all types of Linux configurations, there are at least two broad categories that can directly affect applications’ performances and can largely benefit from ML approaches. First, there are many timing-related configurations in Linux, such as the frequency of interrupting a CPU core (for thread scheduling), the frequency of invoking background swapping (for memory paging), the frequency of flushing buffer cache (for storage), and the sampling rate of CPU clock frequency (for energy and performance). Setting these timing-related configurations is hard, since there are various tradeoffs as- sociated with them. For example, frequent CPU interruption offers the opportunity to improve CPU utilization (with more aggressive thread scheduling) but can cause performance over- head (by preempting and context switching threads), which in turn, reduces effective CPU utilization. Second, there are many configurations on various types of sizes, such as the buffer cache size (for storage caching), disk prefetching amount (for storage access), and swap prefetching amount (for memory paging). Setting these size-related con- figurations is hard, especially when there are tradeoffs among different sizes. For example, a larger buffer cache improves the performance of the storage system but reduces available memory for user applications. Many of the above two types of configurations can con- siderably affect application performance and other important metrics like energy cost. However, the practice of setting them has long been one that involves heavy engineering and hu- man efforts: with heuristics, by trial and error, or with offline experiments. Moreover, once set, they are seldom changed. ML is a better fit for setting these OS configurations. A good ML model trained with past workloads and OS/hardware environments can potentially outperform human-set configu- rations. The model can continue to dynamically generate new configurations to adapt to workload and environment changes. One promising ML technique to generate OS configurations is reinforcement learning. Although reinforcement learning has a more costly inference process, it fits our need well, since OS configurations only need to be re-generated infrequently.
2.2 Learning Policies
There are many decisions that an OS needs to make. These decisions often affect application performance and resource utilization, but rarely affect correctness. ML techniques that can be adapted to different application behaviors dynamically have the potential to outperform current OSes’ global, static policies that are based on heuristics. Below, we discuss several types of OS policies that could be generated with ML. Space allocation. A key task in OSes’ management of hard-
ware resources is space allocation. When an application re- quests for memory or storage spaces, an OS needs to decide which free space to give to the application. A lot of these allocation policies are based on heuristics and simple algo- rithms. For example, Linux allocates virtual memory spaces for mmap system calls using a best-fit policy (i.e., choose the smallest virtual address hole that fits the requested mmap size). The Linux ext family of file systems allocates close-by spaces for files under the same directory. Although these poli- cies work for many workloads and usages, they are not the best choice for all types of applications. For example, files under the same directory are likely to be accessed together, and placing them close to each other can save disk seeks. However, when users access files under different directories, the current ext file systems’ allocation policy does not work well. To better make space allocation decisions, OSes can use ML models to predict candidate locations for allocation. Building good ML models is crucial to the success of ML- based space allocation. A viable approach is to start building models (global, per-user, or per-application) by analyzing his- torical traces of how much space users requested, what space the OS allocated, how efficient spaces are utilized (i.e., how much fragmentation there is), and how users access the al- located space. However, static models are not enough, since application behaviors can change and new types of applica- tions can appear. We expect some online learning techniques will be needed to keep update space-allocation ML models. Scheduling. An OS makes several types of scheduling deci- sions. For CPU scheduling, OSes decide which threads to run on each CPU core. When the time slice of a running process expires or when a process relinquishes its running core, Linux (since v2.6.23) uses the CFS (Completely Fair Scheduling) policy by default to decide which thread to run next. OSes also manage various queues such as network and storage queues. They schedule requests/operations on these queues for bet- ter performance, fairness, and load balancing. Setting good scheduling policy is hard and the criteria of a good policy can change from time to time. For example, before CFS, older versions in Linux use an O(1) CPU scheduler. Rather than hand-tuned scheduling policies, dynamically generated scheduling decisions using ML can greatly ben- efit OSes. Additionally, compared to traditional scheduling policies, ML models have the potential to run faster and save metadata memory space. For example, the Linux CFS sched- uler uses a red-black tree to store available virtual memory address ranges and requires O(logN) time to make a decision. Cache management. Caching is a widely used technique in OSes. OS virtual memory systems store hot data in physical memory and leave the rest in a slower storage device. File systems use in-memory buffer cache to store hot file data and metadata. When managing a cache, OSes need to decide when and which data to evict. Currently, OSes use a set of fixed cache eviction policies, which usually are the result of years
Second, how do we build validation sets? For certain prob- lems, there is ground truth or a theoretical optimum. For exam- ple, for CPU scheduling, theoretically it is best to first run the job with the shortest remaining time (for fastest turn-around time); for page replacement, the theoretical best is to evict the page that will not be used farthest into the future. These theoretically best solution can directly be used as the valida- tion sets during training. However, for other problems, there is no clear best solution. One possible approach is to let users to define their applications’ requirements or objectives by providing reward functions instead of a validation set. OSes can then use reinforcement learning techniques to find the best solution for these requirements/objectives.
3.3 Inference
Different OS learning objectives have different criteria for the speed of inference. The first category of learning only needs to run once in a while or when workload changes, i.e., foreground application operations do not wait for any of these inference results. Configurations and policies all fall into this category. For this type, an inference can run a bit slower, allowing us to explore more costly ML techniques like reinforcement learning. The second category of OS “decisions” must be made very fast, since they are on the application performance critical path. For example, OSes need to decide which thread to sched- ule on a core before the thread can start execution, implying a tight bound of decision making to be within or at most around the time of a context switch. With fast storage and networking devices [ 9 , 20 ], decisions in OS file/storage and network systems also need to be made fast (around or within 1 μs). GPUs and other specialized processors like TPU can make fast prediction with complex models, but invoking them still takes long (1-2μs with today’s PCIe). To be able to make inference fast enough for these OS usages, we either need to reduce this invocation cost or reduce model complexity and run it on a local CPU. Along with the performance overhead of performing infer- ence, there is also the memory space overhead to store ML models for inference. Big models can easily take hundreds MBs of memory. When there are hundreds to thousands of configurations, policies, and mechanisms to learn in an OS, the model space costs can be prohibitively high. A promis- ing approach to reduce memory consumption is leveraging model memory-reuse techniques [ 1 ] in recurrent neural net- works(RNNs).
3.4 Integrating ML in OSes
ML alone cannot make a whole OS. We foresee several chal- lenges in integrating ML models and their predictions into existing OSes. First, while most OS policies are used just for performance improvement and can be sub-optimal or “wrong”, some OS functionalities such as file system and virtual memory map-
pings need to be precise. How to use machine learning tech- niques that are probabilistic in nature to achieve OS deter- ministic tasks is an interesting yet challenging problem. One viable approach is to let ML model first make a range of probabilistic predictions and then use traditional algorithms to compute the final exact answer within this range. The more precise the ML predicted range is, the faster the second step of the exact search can be. Besides correctness guarantee, how to run ML models in kernel space is also a new challenge. Unlike the user space, the kernel space lacks the support of ML libraries. In order for a kernel to use ML techniques, potential options lie between building new kernel-space ML libraries and running ML in user space and then passing results back to the kernel space. The first option requires significant engineering effort while the latter option may suffer from performance loss in context switches. Finally, modern OSes like Linux take a monolithic kernel approach and have become very complex over decades of development efforts. To integrate ML in existing OSes will require careful engineering to minimize the disturbance of the rest of the OSes.
3.5 Security
OSes should offer applications protected accesses to hardware resources. With the learned OS approach, is it safe to use ML models that are learned using application data in OSes? Al- though we envision all security- and protection-related tasks in an OS to still be implemented in the traditional manner, using ML for the rest of the OS kernel can introduce unique security threats and implications. When applying ML technique in OSes, user data will be in- volved indirectly in the control plane of OSes. Without proper protection, malicious users will be able to manipulate both the training and the inference process by feeding carefully crafted data. Doing so can cause OSes to use wrong ML models that work in the attackers’ favor. For example, an attacker can train an ML model to always evict other applications’ mem- ory and launch a denial-of-service attack. It can also generate a bad ML model that causes an OS to constantly miss predict and suffer from deteriorated performance. Using separate ML models for different applications (i.e., isolation of ML) can largely improve the learned OS’ security. However, it is still challenging to protect from side-channel attacks [ 3 ] and to prevent information leakage.
4 Related Work
ML for other low-level systems. The recent work of learned index [ 12 ] proposes to replace traditional tree-based index structures by neural network models that predict the location of data. Learned index has inspired many research works after- wards. In fact, this paper was also inspired by it. A subsequent
work of learned index is SageDB [ 11 ], a learned database sys- tem. It extends learned index with learned Apart from index, it uses ML for merge and hash-join operations. Another ex- tension of learned index is learned bloom filters [ 15 ]. There are also many proposals to use ML for various hardware problems. More relevant is a recent work that predicts mem- ory access patterns and performs memory prefetching using recurrent neural network (RNN) [ 7 ]. ML for OS. Although ML has been used in many domains and recently more in low-level systems, OSes have rarely adopted any ML techniques and most research proposals dated decades back. For example, there are several propos- als of using ML techniques (e.g. C4.5 decision tree, linear regression) to improve application job average turn-around time, for example, by tuning kernel preemption time [ 16 ] and by predicting job run time [ 19 ]. Lynx [ 13 ] is a system that use ML to better perform prefetching from SSDs. It leverages Markov Chains to detect I/O workload patterns and compute the transition probabilities between file pages.
5 Conclusion
Advances in ML techniques and the availability of “big data” and computing resources have made it possible to apply ML in many domains that previously rely on human efforts. We believe that OS is also such a domain. This paper system- atically explores the opportunities and challenges in using ML for OSes. It is of course just a starting point of building real learned OS solutions. We expect more design, develop- ment, and deployment challenges to appear. Nevertheless, we believe learned OS to be a direction that is worth exploring and hope this paper to inspire and help future researchers and practitioners in this area.
Acknowledgments
We would like to thank Jian Huang from Pinterest for his input in the early discussion of this work, which has sub- stantially improved the content of this paper. We would also like to thank the SIGOPS Operating Systems Review editors, Kishore Kumar, Chris Rossbach, and Robbert Van Renesse for their feedback and comments of this paper.
References
[1] Audr unas Gruslys and Remi Munos and Ivo Dani-¯ helka and Marc Lanctot and Alex Graves. Memory- efficient backpropagation through time. In Proceedings of Conference on Neural Information Processing Sys- tems (NeurIPS), 2016. [2] A. M. Caulfield, E. S. Chung, A. Putnam, H. Angepat, J. Fowers, M. Haselman, S. Heil, M. Humphrey, P. Kaur,
J.-Y. Kim, D. Lo, T. Massengill, K. Ovtcharov, M. Pa- pamichael, L. Woods, S. Lanka, D. Chiou, and D. Burger. A cloud-scale acceleration architecture. In 2016 49th An- nual IEEE/ACM International Symposium on Microar- chitecture (MICRO), 2016. [3] V. Duddu, D. Samanta, D. V. Rao, and V. E. Balas. Steal- ing neural networks via timing side channels. arXiv preprint arXiv:1812.11720, 2018. [4] A. Eisenman, D. Gardner, I. AbdelRahman, J. Axboe, S. Dong, K. M. Hazelwood, C. Petersen, A. Cidon, and S. Katti. Reducing dram footprint with nvm in facebook. In Proceedings of the Thirteenth EuroSys Conference,
[5] D. Firestone, A. Putnam, S. Mundkur, D. Chiou, A. Dabagh, M. Andrewartha, H. Angepat, V. Bhanu, A. M. Caulfield, E. S. Chung, H. K. Chandrappa, S. Chaturmohta, M. Humphrey, J. Lavier, N. Lam, F. Liu, K. Ovtcharov, J. Padhye, G. Popuri, S. Raindel, T. Sapre, M. Shaw, G. Silva, M. Sivakumar, N. Srivas- tava, A. Verma, Q. Zuhair, D. Bansal, D. Burger, K. Vaid, D. A. Maltz, and A. G. Greenberg. Azure accelerated networking: Smartnics in the public cloud. In 15th USENIX Symposium on Networked Systems Design and Implementation (NSDI 18), 2018. [6] L. Guo, S. Zhai, Y. Qiao, and F. X. Lin. Transkernel: An executor for commodity kernels on peripheral cores. In 2019 USENIX Annual Technical Conference (USENIX ATC 19), 2019. [7] M. Hashemi, K. J. Swersky, J. A. Smith, G. Ayers, H. Litz, J. Chang, C. Kozyrakis, and P. Ranganathan. Learning memory access patterns. international confer- ence on machine learning, pages 1919–1928, 2018. [8] N. P. Jouppi, C. Young, N. Patil, D. A. Patterson, G. Agrawal, R. Bajwa, S. Bates, S. K. Bhatia, N. Bo- den, A. Borchers, R. Boyle, P. luc Cantin, C. Chao, C. Clark, J. Coriell, M. Daley, M. Dau, J. Dean, B. Gelb, T. V. Ghaemmaghami, R. Gottipati, W. Gulland, R. Hag- mann, C. R. Ho, D. Hogberg, J. Hu, R. Hundt, D. Hurt, J. Ibarz, A. Jaffey, A. Jaworski, A. Kaplan, H. Khaitan, D. Killebrew, A. Koch, N. Kumar, S. Lacy, J. Laudon, J. Law, D. Le, C. Leary, Z. Liu, K. Lucke, A. Lundin, G. MacKean, A. Maggiore, M. Mahony, K. Miller, R. Nagarajan, R. Narayanaswami, R. Ni, K. Nix, T. Nor- rie, M. Omernick, N. Penukonda, A. Phelps, J. Ross, M. Ross, A. Salek, E. Samadiani, C. Severn, G. Sizikov, M. Snelham, J. Souter, D. Steinberg, A. Swing, M. Tan, G. Thorson, B. Tian, H. Toma, E. Tuttle, V. Vasudevan, R. Walter, W. Wang, E. Wilcox, and D. H. Yoon. In- datacenter performance analysis of a tensor processing unit. In 2017 ACM/IEEE 44th Annual International Symposium on Computer Architecture (ISCA), 2017.
