DOCSLIB.ORG

KASHYAP-DISSERTATION-2020.Pdf

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
KASHYAP-DISSERTATION-2020.Pdf SCALING SYNCHRONIZATION PRIMITIVES A Dissertation Presented to The Academic Faculty By Sanidhya Kashyap In Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy in the School of Computer Science Georgia Institute of Technology August 2020 Copyright © Sanidhya Kashyap 2020 SCALING SYNCHRONIZATION PRIMITIVES Approved by: Dr. Taesoo Kim, Advisor School of Computer Science Dr. Irina Calciu Georgia Institute of Technology VMWare Research Dr. Changwoo Min, Co-advisor The Bradley Department of Electri- Dr. Joy Arulraj cal and Computer Engineering School of Computer Science Virginia Tech Georgia Institute of Technology Dr. Ada Gavrilovska Date Approved: June 11, 2020 School of Computer Science Georgia Institute of Technology To maa: for her strength, wisdom, and love. To papa: for his unconditional belief in me. To my brother: for being my critic. To my background thread. ACKNOWLEDGEMENTS I am fortunate to have had the opportunity to collaborate with and learn from amazing people. First, I owe my deepest gratitude to my advisor, Taesoo Kim. Throughout my Ph.D., Taesoo gave me an ample amount of freedom to explore ideas and collaborate with anyone. I am never going to forget these words: “Do whatever you want to do.” His in-depth technical insight, concrete feedback, advice, encouragement, and guidance has led me to where I am today. I hope one day, I can be a good advisor to my future students, as Taesoo has been to me. Another person who had an immeasurable impact on my life is my co-advisor: Chang- woo Min. His vast knowledge of designing parallel systems was essential to realize any of this work. I am never going to forget our discussions, which I still miss. I used to bug him almost every day during his postdoc days, and I still do when I am excited to share some new ideas. I am immensely grateful to him, as he was my mentor, friend, and guide, all at the same time, and continues to do so. In my later part of Ph.D., I was fortunate to work with Irina Calciu. Working with Irina always kept me on edge, as she asked too many (difficult) questions to make me rethink about the work. I hope this continues for the foreseeable future. I also want to thank the other members of my committee: Ada Gavrilovska, and Joy Arulraj. Both of them were always available to discuss ideas and even my career options. I want to thank all the amazing folks that I got to know, learn from, and work with through these years, notably: Sudarsun Kannan, Virendra Maratha, Seulbae Kim, Meng Xu, Insu Yun, Mingwei Shih, Steffen Maass, Mohan Kumar, Tushar Krishna, Fan Sang, Ren Ding, Kyuhong Park, Pradeep Fernando, Mansour Alharthi, Hong Hu, Woonhak Kang, Byoungyoung Lee, Chengyu Song, Woonhak Kang, Wen Xu, Kangnyeon Kim, Hyungon Moon, Seulbae Kim, Meng, Xu, Jean Pierre Lozi, Margo Seltzer, Alex Kogan, Dave Dice, Hong Hu, Hanqing Zhao, Se Kwon Lee, Soujanya Ponnapalli, Madhavan Krishnan iv Ramanathan, Sujin Park, Chulwon Kang, and Xiaohe Cheng. I am really grateful to Seulbae for being a good friend. I want to thank our previous Ph.D. coordinator, Venkat, for his help in navigating various PhD-related administrative issues and even suggesting I work with Taesoo. I am also grateful to our administrative problem-solvers, who made my life easier, especially Elizabeth Ndongi, Trinh Doan, and Sue Jean Chae. Finally, I want to thank my parents for their support and patience along this journey. I want to thank my friend, Jaspal, who has been there through thick and thin, remotely. I am especially grateful to my brother, from whom I have a lot to learn in the arena of life, philosophy, and about myself. v TABLE OF CONTENTS Acknowledgments............................... iv List of Tables................................. x List of Figures................................. xii List of Pseudo-Code............................. xvii Summary.................................... xviii Chapter 1: Introduction........................... 1 1.1 Ordering in Concurrency Control Algorithms ................ 3 1.2 Double Scheduling in Virtualization ..................... 4 1.3 Scalable and Practical Locking Primitives .................. 4 1.4 Outline and Contributions........................... 5 Chapter 2: Background and Motivation................. 6 2.1 A Primer on Multicore Machines....................... 6 2.2 Ordering in Concurrency........................... 7 2.2.1 Multicore Hardware Clocks ..................... 8 2.3 Locking Primitives .............................. 9 2.3.1 Evolution of Lock design....................... 10 vi 2.3.2 Locks in the kernel space (Linux) .................. 12 2.3.3 Locking Bottlenecks in Deployed File Systems ........... 13 2.4 Double Scheduling in VMs.......................... 15 2.5 Conclusion .................................. 17 Chapter 3: Ordering Primitive....................... 18 3.1 Ordo: A Scalable Ordering Primitive..................... 19 3.1.1 Embracing Uncertainty in Clock: Ordo API............. 20 3.1.2 Measuring Uncertainty between Clocks: Calculating ORDO_BOUNDARY 20 3.2 Algorithms with Ordo without Uncertainty.................. 26 3.2.1 Read-Log-Update (RLU)........................ 26 3.2.2 Concurrency Control for Databases ................. 29 3.2.3 Software Transactional Memory (TL2)................ 31 3.2.4 Oplog: An Update-heavy Data Structures Library.......... 33 3.3 Implementation................................ 33 3.4 Evaluation................................... 34 3.4.1 Scalability of Invariant Hardware Clocks............... 36 3.4.2 Evaluating Ordo Primitive ...................... 36 3.4.3 Physical Timestamping: Oplog .................... 38 3.4.4 Read Log Update........................... 39 3.4.5 Concurrency Control Mechanism................... 43 3.4.6 Software Transactional Memory................... 46 3.4.7 Sensitivity Analysis of ORDO_BOUNDARY . 48 vii 3.5 Chapter Summary............................... 49 Chapter 4: Impact of Scheduling on Virtual Machines......... 50 4.1 Design..................................... 51 4.1.1 Lightweight Para-virtualized methods................ 53 4.1.2 Eventual Fairness with Selective Scheduling............. 55 4.2 Use Case.................................... 56 4.3 Implementation................................ 57 4.4 Evaluation................................... 59 4.4.1 Overhead of eCS ............................ 60 4.4.2 Performance in an Over-committed Scenario ............ 61 4.4.3 Performance in an Under-committed Case.............. 67 4.4.4 Addressing BWW Problem via eCS ................... 69 4.4.5 System Eventual Fairness....................... 70 4.5 Chapter Summary............................... 72 Chapter 5: Scalable Locking Primitives.................. 73 5.1 Dominating Factors in Lock Design ..................... 74 5.2 SHFLLOCKS .................................. 77 5.2.1 The Shuffling Mechanism ...................... 78 5.2.2 SHFLLOCKS Design ......................... 78 5.3 Implementation................................ 90 5.4 Evaluation................................... 90 5.4.1 SHFLLOCK Performance Comparison................ 91 viii 5.4.2 Improving Application Performance................. 95 5.4.3 Performance Breakdown....................... 99 5.4.4 Performance With Userspace SHFLLOCK . 101 5.5 Chapter Summary...............................105 Chapter 6: Related Work.......................... 106 6.1 Ordering in Concurrency Control Algorithms . 106 6.2 Double Scheduling in VMs..........................108 6.3 Locking Primitives ..............................110 Chapter 7: Reflections............................ 112 7.1 Limitations ..................................112 7.1.1 Ordering in Concurrency with Ordo . 112 7.1.2 Enlightened Critical Sections.....................113 7.1.3 Shuffling-based Lock Algorithms ..................114 7.2 Future Work..................................115 Chapter 8: Conclusion............................ 117 References................................... 135 ix LIST OF TABLES 2.1 Evolution of synchronization primitives in the last 15 years in Linux along with their introduction with the corresponding Linux version. 11 2.2 Identified lock-based scalability bottlenecks in tested file systems with FxMark [77]. ................................. 14 3.1 Various machine configurations that we use in our evaluation as wellas the calculated offset between cores. While min is the minimum offset between cores, max is the global offset, called ORDO_BOUNDARY (refer to Fig- ure 3.1), which we used, including up to the maximum hardware threads (Cores∗SMT) in a machine. ......................... 36 4.1 Set of para-virtualized methods exposed by the hypervisor to a VM for providing hints to the hypervisor to mitigate double scheduling. These methods provide hints to the hypervisor and VM via shared memory. A vCPU relies on the first four methods to ask for an extra schedule to overcome LHP, LWP, RP, RRP, and ICP. Meanwhile, a vCPU gets hints from the hypervisor by using the last two methods to mitigate LWP and BWW problems. The cpu_id is the core id that is used by tasks running inside a guest OS. yCurrently, is_vcpu_preempted() is already exposed to the VM in Linux. 52 4.2 Applicability of our six lightweight para-virtualized methods that strive to address the symptoms of double scheduling.................. 56 4.3 eCS requires small modifications to the existing Linux kernel, and thean- notation effort is also minimal: 60 LoC changes to support the 10 million LoC Linux kernel that has around 12,000 of lock instances with 85,000
Load more

Recommended publications
  • Is Parallel Programming Hard, And, If So, What Can You Do About It?
    Is Parallel Programming Hard, And, If So, What Can You Do About It? Edited by: Paul E. McKenney Linux Technology Center IBM Beaverton [email protected] December 16, 2011 ii Legal Statement This work represents the views of the authors and does not necessarily represent the view of their employers. IBM, zSeries, and Power PC are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. Linux is a registered trademark of Linus Torvalds. i386 is a trademarks of Intel Corporation or its subsidiaries in the United States, other countries, or both. Other company, product, and service names may be trademarks or service marks of such companies. The non-source-code text and images in this doc- ument are provided under the terms of the Creative Commons Attribution-Share Alike 3.0 United States li- cense (http://creativecommons.org/licenses/ by-sa/3.0/us/). In brief, you may use the contents of this document for any purpose, personal, commercial, or otherwise, so long as attribution to the authors is maintained. Likewise, the document may be modified, and derivative works and translations made available, so long as such modifications and derivations are offered to the public on equal terms as the non-source-code text and images in the original document. Source code is covered by various versions of the GPL (http://www.gnu.org/licenses/gpl-2.0.html). Some of this code is GPLv2-only, as it derives from the Linux kernel, while other code is GPLv2-or-later.
    [Show full text]
  • Demarinis Kent Williams-King Di Jin Rodrigo Fonseca Vasileios P
    sysfilter: Automated System Call Filtering for Commodity Software Nicholas DeMarinis Kent Williams-King Di Jin Rodrigo Fonseca Vasileios P. Kemerlis Department of Computer Science Brown University Abstract This constant stream of additional functionality integrated Modern OSes provide a rich set of services to applications, into modern applications, i.e., feature creep, not only has primarily accessible via the system call API, to support the dire effects in terms of security and protection [1, 71], but ever growing functionality of contemporary software. How- also necessitates a rich set of OS services: applications need ever, despite the fact that applications require access to part of to interact with the OS kernel—and, primarily, they do so the system call API (to function properly), OS kernels allow via the system call (syscall) API [52]—in order to perform full and unrestricted use of the entire system call set. This not useful tasks, such as acquiring or releasing memory, spawning only violates the principle of least privilege, but also enables and terminating additional processes and execution threads, attackers to utilize extra OS services, after seizing control communicating with other programs on the same or remote of vulnerable applications, or escalate privileges further via hosts, interacting with the filesystem, and performing I/O and exploiting vulnerabilities in less-stressed kernel interfaces. process introspection. To tackle this problem, we present sysfilter: a binary Indicatively, at the time of writing, the Linux
    [Show full text]
  • Thread Evolution Kit for Optimizing Thread Operations on CE/Iot Devices
    Thread Evolution Kit for Optimizing Thread Operations on CE/IoT Devices Geunsik Lim , Student Member, IEEE, Donghyun Kang , and Young Ik Eom Abstract—Most modern operating systems have adopted the the threads running on CE/IoT devices often unintentionally one-to-one thread model to support fast execution of threads spend a significant amount of time in taking the CPU resource in both multi-core and single-core systems. This thread model, and the frequency of context switch rapidly increases due to which maps the kernel-space and user-space threads in a one- to-one manner, supports quick thread creation and termination the limited system resources, degrading the performance of in high-performance server environments. However, the perfor- the system significantly. In addition, since CE/IoT devices mance of time-critical threads is degraded when multiple threads usually have limited memory space, they may suffer from the are being run in low-end CE devices with limited system re- segmentation fault [16] problem incurred by memory shortages sources. When a CE device runs many threads to support diverse as the number of threads increases and they remain running application functionalities, low-level hardware specifications often lead to significant resource contention among the threads trying for a long time. to obtain system resources. As a result, the operating system Some engineers have attempted to address the challenges encounters challenges, such as excessive thread context switching of IoT environments such as smart homes by using better overhead, execution delay of time-critical threads, and a lack of hardware specifications for CE/IoT devices [3], [17]–[21].
    [Show full text]
  • Red Hat Enterprise Linux for Real Time 7 Tuning Guide
    Red Hat Enterprise Linux for Real Time 7 Tuning Guide Advanced tuning procedures for Red Hat Enterprise Linux for Real Time Radek Bíba David Ryan Cheryn Tan Lana Brindley Alison Young Red Hat Enterprise Linux for Real Time 7 Tuning Guide Advanced tuning procedures for Red Hat Enterprise Linux for Real Time Radek Bíba Red Hat Customer Content Services [email protected] David Ryan Red Hat Customer Content Services [email protected] Cheryn Tan Red Hat Customer Content Services Lana Brindley Red Hat Customer Content Services Alison Young Red Hat Customer Content Services Legal Notice Copyright © 2015 Red Hat, Inc. This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
    [Show full text]
  • SUSE Linux Enterprise Server 12 SP4 System Analysis and Tuning Guide System Analysis and Tuning Guide SUSE Linux Enterprise Server 12 SP4
    SUSE Linux Enterprise Server 12 SP4 System Analysis and Tuning Guide System Analysis and Tuning Guide SUSE Linux Enterprise Server 12 SP4 An administrator's guide for problem detection, resolution and optimization. Find how to inspect and optimize your system by means of monitoring tools and how to eciently manage resources. Also contains an overview of common problems and solutions and of additional help and documentation resources. Publication Date: September 24, 2021 SUSE LLC 1800 South Novell Place Provo, UT 84606 USA https://documentation.suse.com Copyright © 2006– 2021 SUSE LLC and contributors. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”. For SUSE trademarks, see https://www.suse.com/company/legal/ . All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its aliates. Asterisks (*) denote third-party trademarks. All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its aliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof. Contents About This Guide xii 1 Available Documentation xiii
    [Show full text]
  • 11. Kernel Design 11
    11. Kernel Design 11. Kernel Design Interrupts and Exceptions Low-Level Synchronization Low-Level Input/Output Devices and Driver Model File Systems and Persistent Storage Memory Management Process Management and Scheduling Operating System Trends Alternative Operating System Designs 269 / 352 11. Kernel Design Bottom-Up Exploration of Kernel Internals Hardware Support and Interface Asynchronous events, switching to kernel mode I/O, synchronization, low-level driver model Operating System Abstractions File systems, memory management Processes and threads Specific Features and Design Choices Linux 2.6 kernel Other UNIXes (Solaris, MacOS), Windows XP and real-time systems 270 / 352 11. Kernel Design – Interrupts and Exceptions 11. Kernel Design Interrupts and Exceptions Low-Level Synchronization Low-Level Input/Output Devices and Driver Model File Systems and Persistent Storage Memory Management Process Management and Scheduling Operating System Trends Alternative Operating System Designs 271 / 352 11. Kernel Design – Interrupts and Exceptions Hardware Support: Interrupts Typical case: electrical signal asserted by external device I Filtered or issued by the chipset I Lowest level hardware synchronization mechanism Multiple priority levels: Interrupt ReQuests (IRQ) I Non-Maskable Interrupts (NMI) Processor switches to kernel mode and calls specific interrupt service routine (or interrupt handler) Multiple drivers may share a single IRQ line IRQ handler must identify the source of the interrupt to call the proper → service routine 272 / 352 11. Kernel Design – Interrupts and Exceptions Hardware Support: Exceptions Typical case: unexpected program behavior I Filtered or issued by the chipset I Lowest level of OS/application interaction Processor switches to kernel mode and calls specific exception service routine (or exception handler) Mechanism to implement system calls 273 / 352 11.
    [Show full text]
  • Greg Kroah-Hartman [email protected] Github.Com/Gregkh/Presentation-Kdbus
    kdbus IPC for the modern world Greg Kroah-Hartman [email protected] github.com/gregkh/presentation-kdbus Interprocess Communication ● signal ● synchronization ● communication standard signals realtime The Linux Programming Interface, Michael Kerrisk, page 878 POSIX semaphore futex synchronization named eventfd unnamed semaphore System V semaphore “record” lock file lock file lock mutex threads condition variables barrier read/write lock The Linux Programming Interface, Michael Kerrisk, page 878 data transfer pipe communication FIFO stream socket pseudoterminal POSIX message queue message System V message queue memory mapping System V shared memory POSIX shared memory shared memory memory mapping Anonymous mapping mapped file The Linux Programming Interface, Michael Kerrisk, page 878 Android ● ashmem ● pmem ● binder ashmem ● POSIX shared memory for the lazy ● Uses virtual memory ● Can discard segments under pressure ● Unknown future pmem ● shares memory between kernel and user ● uses physically contigous memory ● GPUs ● Unknown future binder ● IPC bus for Android system ● Like D-Bus, but “different” ● Came from system without SysV types ● Works on object / message level ● Needs large userspace library ● NEVER use outside an Android system binder ● File descriptor passing ● Used for Intents and application separation ● Good for small messages ● Not for streams of data ● NEVER use outside an Android system QNX message passing ● Tight coupling to microkernel ● Send message and control, to another process ● Used to build complex messages
    [Show full text]
  • Understanding the Linux Kernel, 3Rd Edition by Daniel P
    1 Understanding the Linux Kernel, 3rd Edition By Daniel P. Bovet, Marco Cesati ............................................... Publisher: O'Reilly Pub Date: November 2005 ISBN: 0-596-00565-2 Pages: 942 Table of Contents | Index In order to thoroughly understand what makes Linux tick and why it works so well on a wide variety of systems, you need to delve deep into the heart of the kernel. The kernel handles all interactions between the CPU and the external world, and determines which programs will share processor time, in what order. It manages limited memory so well that hundreds of processes can share the system efficiently, and expertly organizes data transfers so that the CPU isn't kept waiting any longer than necessary for the relatively slow disks. The third edition of Understanding the Linux Kernel takes you on a guided tour of the most significant data structures, algorithms, and programming tricks used in the kernel. Probing beyond superficial features, the authors offer valuable insights to people who want to know how things really work inside their machine. Important Intel-specific features are discussed. Relevant segments of code are dissected line by line. But the book covers more than just the functioning of the code; it explains the theoretical underpinnings of why Linux does things the way it does. This edition of the book covers Version 2.6, which has seen significant changes to nearly every kernel subsystem, particularly in the areas of memory management and block devices. The book focuses on the following topics: • Memory management, including file buffering, process swapping, and Direct memory Access (DMA) • The Virtual Filesystem layer and the Second and Third Extended Filesystems • Process creation and scheduling • Signals, interrupts, and the essential interfaces to device drivers • Timing • Synchronization within the kernel • Interprocess Communication (IPC) • Program execution Understanding the Linux Kernel will acquaint you with all the inner workings of Linux, but it's more than just an academic exercise.
    [Show full text]
  • Futexes Are Tricky
    Futexes Are Tricky Ulrich Drepper Red Hat, Inc. [email protected] January 31, 2008 Abstract Starting with early version of the 2.5 series, the Linux kernel contains a light-weight method for process synchronization. It is used in the modern thread library implementation but is also useful when used directly. This article introduces the concept and user level code to use them. 1 Preface addr1. It has a size of 4 bytes on all platforms, 32-bit and 64-bit. The value of the variable is fully under the control 1 The base reference for futexes has been “Fuss, Futexes of the application. No value has a specific meaning. and Furwocks: Fast User Level Locking in Linux” writ- ten by Franke, Russell, and Kirkwood, released in the Any memory address in regular memory (excluding some- proceedings of the 2002 OLS [1]. This document is still thing like DMA areas etc) can be used for the futex. The mostly valid. But the kernel functionality got extended only requirement is that the variable is aligned at a mul- and generally improved. The biggest weakness, though, tiple of sizeof(int). is the lack of instruction on how to use futexes correctly. Rusty Russell distributes a package containing user level It is not obvious from the prototype, but the kernel han- code (ftp://ftp.kernel.org/pub/linux/kernel/people/rusty/) dles the actual physical addresses of the futexes. I.e., if but unfortunately this code is not very well documented two processes reference a futex in a memory region they and worse, as of this writing the code is actually incor- share, they will reference the same futex object.
    [Show full text]
  • Linux Kernel Synchronization
    10/27/12 Logical Diagram Binary Memory Threads Formats Allocators Linux kernel Today’s Lecture User SynchronizationSystem Calls Kernel synchronization in the kernel RCU File System Networking Sync Don Porter CSE 506 Memory Device CPU Management Drivers Scheduler Hardware Interrupts Disk Net Consistency Why Linux Warm-up synchronization? ò What is synchronization? ò A modern OS kernel is one of the most complicated parallel programs you can study ò Code on multiple CPUs coordinate their operations ò Examples: ò Other than perhaps a database ò Includes most common synchronization patterns ò Locking provides mutual exclusion while changing a pointer-based data structure ò And a few interesting, uncommon ones ò Threads might wait at a barrier for completion of a phase of computation ò Coordinating which CPU handles an interrupt The old days: They didn’t Historical perspective worry! ò Why did OSes have to worry so much about ò Early/simple OSes (like JOS, pre-lab4): No need for synchronization back when most computers have only synchronization one CPU? ò All kernel requests wait until completion – even disk requests ò Heavily restrict when interrupts can be delivered (all traps use an interrupt gate) ò No possibility for two CPUs to touch same data 1 10/27/12 Slightly more recently A slippery slope ò Optimize kernel performance by blocking inside the kernel ò We can enable interrupts during system calls ò Example: Rather than wait on expensive disk I/O, block and ò More complexity, lower latency schedule another process until it completes ò We can block in more places that make sense ò Cost: A bit of implementation complexity ò Better CPU usage, more complexity ò Need a lock to protect against concurrent update to pages/ inodes/etc.
    [Show full text]
  • Towards Scalable Synchronization on Multi-Cores
    Towards Scalable Synchronization on Multi-Cores THÈSE NO 7246 (2016) PRÉSENTÉE LE 21 OCTOBRE 2016 À LA FACULTÉ INFORMATIQUE ET COMMUNICATIONS LABORATOIRE DE PROGRAMMATION DISTRIBUÉE PROGRAMME DOCTORAL EN INFORMATIQUE ET COMMUNICATIONS ÉCOLE POLYTECHNIQUE FÉDÉRALE DE LAUSANNE POUR L'OBTENTION DU GRADE DE DOCTEUR ÈS SCIENCES PAR Vasileios TRIGONAKIS acceptée sur proposition du jury: Prof. J. R. Larus, président du jury Prof. R. Guerraoui, directeur de thèse Dr T. Harris, rapporteur Dr G. Muller, rapporteur Prof. W. Zwaenepoel, rapporteur Suisse 2016 “We can only see a short distance ahead, but we can see plenty there that needs to be done.” — Alan Turing To my parents, Eirini and Charalampos Acknowledgements “The whole is greater than the sum of its parts.” — Aristotle To date, my education (i.e., diploma, M.Sc., and Ph.D.) has lasted for 13 years. I could not possibly be here and sustain all the pressure (and of course the financial expenses) without the help and support of my family, Eirini (my mother), Charalampos (my father), and Eleni (my sister). I want to deeply thank them for being there for me throughout these years. In my experience, a successful Ph.D. thesis in the area called “systems” (i.e., with a focus on software systems) requires either 10 years of solo work, or 5–6 years of fruitful collaborations. I was lucky enough to belong in the latter category and to have the chance to collaborate with many amazing people in producing the research that is included in this dissertation. This is actually the main reason why in the main body of this dissertation I use “we” instead of “I.” First and foremost, I would like to thank my advisor, Rachid Guerraoui.
    [Show full text]
  • Petalinux Tools Documentation: Reference Guide
    See all versions of this document PetaLinux Tools Documentation Reference Guide UG1144 (v2021.1) June 16, 2021 Revision History Revision History The following table shows the revision history for this document. Section Revision Summary 06/16/2021 Version 2021.1 Chapter 7: Customizing the Project Added a new section: Configuring UBIFS Boot. Chapter 5: Booting and Packaging Updated Steps to Boot a PetaLinux Image on Hardware with SD Card. Appendix A: Migration Added FPGA Manager Changes, Yocto Recipe Name Changes, Host GCC Version Upgrade. Chapter 10: Advanced Configurations Updated U-Boot Configuration and Image Packaging Configuration. UG1144 (v2021.1) June 16, 2021Send Feedback www.xilinx.com PetaLinux Tools Documentation Reference Guide 2 Table of Contents Revision History...............................................................................................................2 Chapter 1: Overview.................................................................................................... 8 Introduction................................................................................................................................. 8 Navigating Content by Design Process.................................................................................... 9 Chapter 2: Setting Up Your Environment...................................................... 11 Installation Steps.......................................................................................................................11 PetaLinux Working Environment Setup................................................................................
    [Show full text]