DOCSLIB.ORG

The Lttng Tracer: a Low Impact Performance and Behavior Monitor for GNU/Linux

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Lttng Tracer: a Low Impact Performance and Behavior Monitor for GNU/Linux The LTTng tracer: A low impact performance and behavior monitor for GNU/Linux Mathieu Desnoyers Michel R. Dagenais École Polytechnique de Montréal École Polytechnique de Montréal [email protected] [email protected] Abstract presented. The approach taken to allow nested types, variable fields and dynamic alignment of data in the trace buffers will be revealed. It will Efficient tracing of system-wide execution, show the mechanisms deployed to facilitate use allowing integrated analysis of both kernel and extension of this tool by adding custom in- space and user space, is something difficult to strumentation and analysis involving kernel, li- achieve. The following article will present you braries and user space programs. a new tracer core, Linux Trace Toolkit Next Generation (LTTng), that has taken over the It will also introduce LTTng’s trace analyzer previous version known as LTT. It has the same and graphical viewer counterpart: Linux Trace goals of low system disturbance and architec- Toolkit Viewer (LTTV). The latter implements ture independance while being fully reentrant, extensible analysis of the trace information scalable, precise, extensible, modular and easy through collaborating text and graphical plu- to use. For instance, LTTng allows tracepoints gins.1 It can simultaneously display multi- in NMI code, multiple simultaneous traces and ple multi-GBytes traces of multi-processor sys- a flight recorder mode. LTTng reuses and en- tems. hances the existing LTT instrumentation and RelayFS. This paper will focus on the approaches taken 1 Tracing goals by LTTng to fulfill these goals. It will present the modular architecture of the project. It With the increasing complexity of newer com- will then explain how NMI reentrancy requires puter systems, the overall performance of appli- atomic operations for writing and RCU lists for cations often depends on a combination of sev- tracing behavior control. It will show how these eral factors including I/O subsystems, device techniques are inherently scalable to multipro- drivers, interrupts, lock contention among mul- cessor systems. Then, time precision limita- tiple CPUs, scheduling and memory manage- tions in the kernel will be discussed, followed ment. A low impact, high performance, trac- by an explanation of LTTng’s own monotonic ing system may therefore be the only tool ca- timestamps motives. pable of collecting the information produced by instrumenting the whole system, while not In addition, the template based code generator for architecture agnostic trace format will be 1Project website: http://ltt.polymtl.ca. 210 • The LTTng tracer: A low impact performance and behavior monitor for GNU/Linux changing significantly the studied system be- aims to minimize CPU usage during the exe- havior and performance. cution of the monitored system by collecting data for later off-line analysis. As the goal is to Besides offering a flexible and easy to use in- have minimum impact on performance, static terface to users, an efficient tracer must satisfy instrumentation is habitually used in this ap- the requirements of the most demanding appli- proach. Static instrumentation consists in mod- cation. For instance, the widely used printk ifying the program source code to add logging and printf statements are relatively easy to statements that will compile with the program. use and are correct for simple applications, but Such systems include LTT [7], a Linux ker- do not offer the needed performance for instru- nel Tracer, K42 [5], a research operating sys- menting interrupts in high performance multi- tem from IBM, IrixView and Tornado which processor computer systems and cannot neces- are commercial proprietary products. sarily be used in some code paths such as non maskable interrupts (NMI) handlers. The second class of monitor aims at calculating An important aspect of tracing, particularly in well defined information (e.g. I/O requests per the real-time and high performance comput- seconds, system calls per second per PID) on ing fields, is the precision of events times- the monitored CPU itself: it is what is generally tamps. Real-time is often used in embedded called a pre-processing approach. It is the case systems which are based on a number of dif- of SystemTAP [3], Kerninst [4], Sun’s dtrace ferent architectures (e.g. ARM, MIPS, PPC) [1] and IBM’s Performance and Environment optimized for various applications. The chal- Monitoring (PEM) [6]. All except PEM use a lenge is therefore to obtain a tracer with precise dynamic instrumentation approach. Dynamic timestamps, across multiple architectures, run- instrumentation is performed by changing as- ning from several MHz to several GHz, some sembly instructions for breakpoints in the pro- being multi-processors. gram binary objects loaded in memory, like the gdb debugger does. It is suitable to their goal The number of ad hoc tracing systems devised because it generally has a negligible footprint for specific needs (several Linux device drivers compared to the pre-processing they do. contain a small tracer), and the experience with earlier versions of LTT, show the needs for a flexible and extensible system. This is the case Since our goal is to support high performance both in terms of adding easily new instrumen- and real-time embedded systems, the dynamic tation points and in terms of adding plugins for probe approach is too intrusive, as it implies the analysis and display of the resulting trace using a costly breakpoint interrupt. Further- data. more, even if the pre-processing of information can sometimes be faster than logging raw data, it does not allow the same flexibility as post- 2 Existing solutions processing analysis. Indeed, almost every as- pect of a system can be studied once is obtained a trace of the complete flow of the system be- Several different approaches have been taken havior. However, pre-processed data can be by performance monitoring tools. They usually logged into a tracer, as does PEM with K42, for adhere to one of the following two paradigms. later combined analysis, and the two are there- The first class of monitor, post-processing, fore not incompatible. 2006 Linux Symposium, Volume One • 211 3 Previous Works been done in collaboration with members of their team. The XML file format for describ- ing events came from these discussions, aiming LTTng reuses research that has been previously at standardizing event description and trace for- done in the operating system tracing field in or- mats. der to build new features and address currently unsolved questions more thoroughly. The previous Linux Trace Toolkit (LTT) [7] 4 The LTTng approach project offers an operating system instrumen- tation that has been quite stable through the 2.6 Linux kernels. It also has the advantage of be- The following subsections describe the five ing cross-platform, but with types limited to main components of the LTTng architecture. fixed sizes (e.g. fixed 8, 16, 32, or 64-byte inte- The first one explains the control of the differ- gers compared to host size byte, short, integer, ent entities in LTTng. It is followed by a de- and long). It also suffers from the monolithic scription of the data flow in the different mod- implementation of both the LTT tracer and its ules of the application. The automated static viewer which have proven to be difficult to ex- instrumentation will thereafter be introduced. tend. Another limitation is the use of the ker- Event type registration, the mecanism that links nel NTP corrected time for timestamps, which the extensible instrumentation to the dynamic is not monotonic. LTTng is based on LTT but collection of traces, will then be presented. is a new generation, layered, easily extensible with new event types and viewer plugins, with a more precise time base and that will eventu- 4.1 Control ally support the combined analysis of several computers in a cluster [2]. There are three main parts in LTTng: a user RelayFS [8] has been developed as a standard space command-line application, lttctl; a user high-speed data relay between the kernel and space daemon, lttd, that waits for trace data and user space. It has been integrated in the 2.6.14 writes it to disk; and a kernel part that controls Linux kernels. It offers hooks for kernel clients kernel tracing. Figure 1 shows the control paths to send information in large buffers and inter- in LTTng. lttctl is the command line application acts with a user space daemon through file op- used to control tracing. It starts a lttd and con- erations on a memory mapped file. trols kernel tracing behavior through a library- module bridge which uses a netlink socket. IBM, in the past years, has developed K42 [5], an open source research kernel which aims at The core module of LTTng is ltt-core. This full scalability. It has been designed from the module is responsible for a number of LTT ground up with tracing being a necessity, not an control events. It controls helper modules option. It offers a very elegant lockless tracing ltt-heartbeat, ltt-facilities, and ltt-statedump. mechanism based on the atomic compare-and- Module ltt-heartbeat generates periodic events exchange operation. in order to detect and account for cycle coun- ters overflows, thus allowing a single monoton- The Performance and Environment Monitor- ically increasing time base even if shorter 32- ing (PEM) [6] project shares a few similarities bit (instead of 64-bit) cycle counts are stored with LTTng and LTTV since some work have in each event. Ltt-facilities lists the facilities 212 • The LTTng tracer: A low impact performance and behavior monitor for GNU/Linux User space trace files User space lttd lttctl liblttctl libltt-usertrace-fast lttd Kernel-User Communication Netlink socket RelayFS Kernel-User RelayFS Communication Kernel ltt-control modules ltt-statedump ltt-core Kernel ltt-base Built-in Kernel ltt-base built-in Figure 2: LTTng data flow ltt-heartbeat ltt-facilities data by using the poll file operation.
Load more

Recommended publications
  • Lttng and the Love of Development Without Printf() [email protected]
    Fosdem 2014 + LTTng and the love of development without printf() [email protected] 1 whoami David Goulet, Software Developer, EfficiOS, Maintainer of LTTng-tools project ● https://git.lttng.org//lttng-tools.git 2 Content Quick overview of LTTng 2.x Everything else you need to know! Recent features & future work. 3 What is tracing? ● Recording runtime information without stopping the process – Enable/Disable event(s) at runtime ● Usually used during development to solve problems like performance, races, etc... ● Lots of possibilities on Linux: LTTng, Perf, ftrace, SystemTap, strace, ... 4 OverviewOverview ofof LTTngLTTng 2.x2.x 5 Overview of LTTng 2.x Unified user interface, kernel and user space tracers combined. (No need to recompile kernel) Trace output in a unified format (CTF) – https://git.efficios.com/ctf.git Low overhead, Shipped in distros: Ubuntu, Debian, Suse, Fedora, Linaro, Wind River, etc. 6 Tracers ● lttng-modules: kernel tracer module, compatible with kernels from 2.6.38* to 3.13.x, ● lttng-ust: user-space tracer, in-process library. * Kernel tracing is now possible on 2.6.32 to 2.6.37 by backport of 3 Linux Kernel patches. 7 Utilities ● lttng-tools: cli utilities and daemons for trace control, – lttng: cli utility for tracing control, – lttng-ctl: tracing control API, – lttng-sessiond: tracing registry daemon, – lttng-consumerd: extract trace data, – lttng-relayd: network streaming daemon. 8 Viewers ● babeltrace: cli text viewer, trace converter, plugin system, ● lttngtop: ncurse top-like viewer, ● Eclipse lttng plugin: front-end for lttng, collect, visualize and analyze traces, highly extensible. 9 LTTng-UST – How does it work? Users instrument their applications with static tracepoints, liblttng-ust, in-process library, dynamically linked with application, Session setup, etc., Run app, collect traces, Post analysis with viewers.
    [Show full text]
  • A Comprehensive Review for Central Processing Unit Scheduling Algorithm
    IJCSI International Journal of Computer Science Issues, Vol. 10, Issue 1, No 2, January 2013 ISSN (Print): 1694-0784 | ISSN (Online): 1694-0814 www.IJCSI.org 353 A Comprehensive Review for Central Processing Unit Scheduling Algorithm Ryan Richard Guadaña1, Maria Rona Perez2 and Larry Rutaquio Jr.3 1 Computer Studies and System Department, University of the East Caloocan City, 1400, Philippines 2 Computer Studies and System Department, University of the East Caloocan City, 1400, Philippines 3 Computer Studies and System Department, University of the East Caloocan City, 1400, Philippines Abstract when an attempt is made to execute a program, its This paper describe how does CPU facilitates tasks given by a admission to the set of currently executing processes is user through a Scheduling Algorithm. CPU carries out each either authorized or delayed by the long-term scheduler. instruction of the program in sequence then performs the basic Second is the Mid-term Scheduler that temporarily arithmetical, logical, and input/output operations of the system removes processes from main memory and places them on while a scheduling algorithm is used by the CPU to handle every process. The authors also tackled different scheduling disciplines secondary memory (such as a disk drive) or vice versa. and examples were provided in each algorithm in order to know Last is the Short Term Scheduler that decides which of the which algorithm is appropriate for various CPU goals. ready, in-memory processes are to be executed. Keywords: Kernel, Process State, Schedulers, Scheduling Algorithm, Utilization. 2. CPU Utilization 1. Introduction In order for a computer to be able to handle multiple applications simultaneously there must be an effective way The central processing unit (CPU) is a component of a of using the CPU.
    [Show full text]
  • The Different Unix Contexts
    The different Unix contexts • User-level • Kernel “top half” - System call, page fault handler, kernel-only process, etc. • Software interrupt • Device interrupt • Timer interrupt (hardclock) • Context switch code Transitions between contexts • User ! top half: syscall, page fault • User/top half ! device/timer interrupt: hardware • Top half ! user/context switch: return • Top half ! context switch: sleep • Context switch ! user/top half Top/bottom half synchronization • Top half kernel procedures can mask interrupts int x = splhigh (); /* ... */ splx (x); • splhigh disables all interrupts, but also splnet, splbio, splsoftnet, . • Masking interrupts in hardware can be expensive - Optimistic implementation – set mask flag on splhigh, check interrupted flag on splx Kernel Synchronization • Need to relinquish CPU when waiting for events - Disk read, network packet arrival, pipe write, signal, etc. • int tsleep(void *ident, int priority, ...); - Switches to another process - ident is arbitrary pointer—e.g., buffer address - priority is priority at which to run when woken up - PCATCH, if ORed into priority, means wake up on signal - Returns 0 if awakened, or ERESTART/EINTR on signal • int wakeup(void *ident); - Awakens all processes sleeping on ident - Restores SPL a time they went to sleep (so fine to sleep at splhigh) Process scheduling • Goal: High throughput - Minimize context switches to avoid wasting CPU, TLB misses, cache misses, even page faults. • Goal: Low latency - People typing at editors want fast response - Network services can be latency-bound, not CPU-bound • BSD time quantum: 1=10 sec (since ∼1980) - Empirically longest tolerable latency - Computers now faster, but job queues also shorter Scheduling algorithms • Round-robin • Priority scheduling • Shortest process next (if you can estimate it) • Fair-Share Schedule (try to be fair at level of users, not processes) Multilevel feeedback queues (BSD) • Every runnable proc.
    [Show full text]
  • Flame Graphs Freebsd
    FreeBSD Developer and Vendor Summit, Nov, 2014 Flame Graphs on FreeBSD Brendan Gregg Senior Performance Architect Performance Engineering Team [email protected] @brendangregg Agenda 1. Genesis 2. Generaon 3. CPU 4. Memory 5. Disk I/O 6. Off-CPU 7. Chain 1. Genesis The Problem • The same MySQL load on one host runs at 30% higher CPU than another. Why? • CPU profiling should answer this easily # dtrace -x ustackframes=100 -n 'profile-997 /execname == "mysqld"/ {! @[ustack()] = count(); } tick-60s { exit(0); }'! dtrace: description 'profile-997 ' matched 2 probes! CPU ID FUNCTION:NAME! 1 75195 :tick-60s! [...]! libc.so.1`__priocntlset+0xa! libc.so.1`getparam+0x83! libc.so.1`pthread_getschedparam+0x3c! libc.so.1`pthread_setschedprio+0x1f! mysqld`_Z16dispatch_command19enum_server_commandP3THDPcj+0x9ab! mysqld`_Z10do_commandP3THD+0x198! mysqld`handle_one_connection+0x1a6! libc.so.1`_thrp_setup+0x8d! libc.so.1`_lwp_start! 4884! ! mysqld`_Z13add_to_statusP17system_status_varS0_+0x47! mysqld`_Z22calc_sum_of_all_statusP17system_status_var+0x67! mysqld`_Z16dispatch_command19enum_server_commandP3THDPcj+0x1222! mysqld`_Z10do_commandP3THD+0x198! mysqld`handle_one_connection+0x1a6! libc.so.1`_thrp_setup+0x8d! libc.so.1`_lwp_start! 5530! # dtrace -x ustackframes=100 -n 'profile-997 /execname == "mysqld"/ {! @[ustack()] = count(); } tick-60s { exit(0); }'! dtrace: description 'profile-997 ' matched 2 probes! CPU ID FUNCTION:NAME! 1 75195 :tick-60s! [...]! libc.so.1`__priocntlset+0xa! libc.so.1`getparam+0x83! this stack libc.so.1`pthread_getschedparam+0x3c!
    [Show full text]
  • Comparing Systems Using Sample Data
    Operating System and Process Monitoring Tools Arik Brooks, [email protected] Abstract: Monitoring the performance of operating systems and processes is essential to debug processes and systems, effectively manage system resources, making system decisions, and evaluating and examining systems. These tools are primarily divided into two main categories: real time and log-based. Real time monitoring tools are concerned with measuring the current system state and provide up to date information about the system performance. Log-based monitoring tools record system performance information for post-processing and analysis and to find trends in the system performance. This paper presents a survey of the most commonly used tools for monitoring operating system and process performance in Windows- and Unix-based systems and describes the unique challenges of real time and log-based performance monitoring. See Also: Table of Contents: 1. Introduction 2. Real Time Performance Monitoring Tools 2.1 Windows-Based Tools 2.1.1 Task Manager (taskmgr) 2.1.2 Performance Monitor (perfmon) 2.1.3 Process Monitor (pmon) 2.1.4 Process Explode (pview) 2.1.5 Process Viewer (pviewer) 2.2 Unix-Based Tools 2.2.1 Process Status (ps) 2.2.2 Top 2.2.3 Xosview 2.2.4 Treeps 2.3 Summary of Real Time Monitoring Tools 3. Log-Based Performance Monitoring Tools 3.1 Windows-Based Tools 3.1.1 Event Log Service and Event Viewer 3.1.2 Performance Logs and Alerts 3.1.3 Performance Data Log Service 3.2 Unix-Based Tools 3.2.1 System Activity Reporter (sar) 3.2.2 Cpustat 3.3 Summary of Log-Based Monitoring Tools 4.
    [Show full text]
  • A Simple Chargeback System for SAS® Applications Running on UNIX and Linux Servers
    SAS Global Forum 2007 Systems Architecture Paper: 194-2007 A Simple Chargeback System For SAS® Applications Running on UNIX and Linux Servers Michael A. Raithel, Westat, Rockville, MD Abstract Organizations that run SAS on UNIX and Linux servers often have a need to measure overall SAS usage and to charge the projects and users who utilize the servers. This allows an organization to pay for the hardware, software, and labor necessary to maintain and run these types of shared servers. However, performance management and accounting software is normally expensive. Purchasing such software, configuring it, and managing it may be prohibitive in terms of cost and in terms of having staff with the right skill sets to do so. Consequently, many organizations with UNIX or Linux servers do not have a reliable way to measure the overall use of SAS software and to charge individuals and projects for its use. This paper presents a simple methodology for creating a chargeback system on UNIX and Linux servers. It uses basic accounting programs found in the UNIX and Linux operating systems, and exploits them using SAS software. The paper presents an overview of the UNIX/Linux “sa” command and the basic accounting system. Then, it provides a SAS program that utilizes this command to capture and store monthly SAS usage statistics. The paper presents a second SAS program that reads the monthly SAS usage SAS data set and creates both a chargeback report and a general usage report. After reading this paper, you should be able to easily adapt the sample SAS programs to run on servers in your own environment.
    [Show full text]
  • Linuxcon North America 2012
    LinuxCon North America 2012 LTTng 2.0 : Tracing, Analysis and Views for Performance and Debugging. E-mail: [email protected] Mathieu Desnoyers August 29th, 2012 1 > Presenter ● Mathieu Desnoyers ● EfficiOS Inc. ● http://www.efficios.com ● Author/Maintainer of ● LTTng, LTTng-UST, Babeltrace, Userspace RCU Mathieu Desnoyers August 29th, 2012 2 > Content ● Tracing benefits, ● LTTng 2.0 Linux kernel and user-space tracers, ● LTTng 2.0 usage scenarios & viewers, ● New features ready for LTTng 2.1, ● Conclusion Mathieu Desnoyers August 29th, 2012 3 > Benefits of low-impact tracing in a multi-core world ● Understanding interaction between ● Kernel ● Libraries ● Applications ● Virtual Machines ● Debugging ● Performance tuning ● Monitoring Mathieu Desnoyers August 29th, 2012 4 > Tracing use-cases ● Telecom ● Operator, engineer tracing systems concurrently with different instrumentation sets. ● In development and production phases. ● High-availability, high-throughput servers ● Development and production: ensure high performance, low-latency in production. ● Embedded ● System development and production stages. Mathieu Desnoyers August 29th, 2012 5 > LTTng 2.0 ● Rich ecosystem of projects, ● Key characteristics of LTTng 2.0: – Small impact on the traced system, fast, user- oriented features. ● Interfacing with: Common Trace Format (CTF) Interoperability Between Tracing Tools Tracing Well With Others: Integration with the Common Trace Format (CTF), of GDB Tracepoints Into Trace Tools, Mathieu Desnoyers, EfficiOS, Stan Shebs, Mentor Graphics,
    [Show full text]
  • Linux Performance Tools
    Linux Performance Tools Brendan Gregg Senior Performance Architect Performance Engineering Team [email protected] @brendangregg This Tutorial • A tour of many Linux performance tools – To show you what can be done – With guidance for how to do it • This includes objectives, discussion, live demos – See the video of this tutorial Observability Benchmarking Tuning Stac Tuning • Massive AWS EC2 Linux cloud – 10s of thousands of cloud instances • FreeBSD for content delivery – ~33% of US Internet traffic at night • Over 50M subscribers – Recently launched in ANZ • Use Linux server tools as needed – After cloud monitoring (Atlas, etc.) and instance monitoring (Vector) tools Agenda • Methodologies • Tools • Tool Types: – Observability – Benchmarking – Tuning – Static • Profiling • Tracing Methodologies Methodologies • Objectives: – Recognize the Streetlight Anti-Method – Perform the Workload Characterization Method – Perform the USE Method – Learn how to start with the questions, before using tools – Be aware of other methodologies My system is slow… DEMO & DISCUSSION Methodologies • There are dozens of performance tools for Linux – Packages: sysstat, procps, coreutils, … – Commercial products • Methodologies can provide guidance for choosing and using tools effectively • A starting point, a process, and an ending point An#-Methodologies • The lack of a deliberate methodology… Street Light An<-Method 1. Pick observability tools that are: – Familiar – Found on the Internet – Found at random 2. Run tools 3. Look for obvious issues Drunk Man An<-Method • Tune things at random until the problem goes away Blame Someone Else An<-Method 1. Find a system or environment component you are not responsible for 2. Hypothesize that the issue is with that component 3. Redirect the issue to the responsible team 4.
    [Show full text]
  • Advanced Linux Tracing Technologies for Online Surveillance of Software Systems
    Advanced Linux tracing technologies for Online Surveillance of Software Systems M. Couture DRDC – Valcartier Research Centre Defence Research and Development Canada Scientific Report DRDC-RDDC-2015-R211 October 2015 © Her Majesty the Queen in Right of Canada, as represented by the Minister of National Defence, 2015 © Sa Majesté la Reine (en droit du Canada), telle que représentée par le ministre de la Défense nationale, 2015 Abstract This scientific report provides a description of the concepts and technologies that were developed in the Poly-Tracing Project. The main product that was made available at the end of this four-year project is a new software tracer called Linux Trace Toolkit next generation (LTTng). LTTng actually represents the centre of gravity around which much more applied research and development took place in the project. As shown in this document, the technologies that were produced allow the exploitation of the LTTng tracer and its output for two main purposes: a- solving today’s increasingly complex software bugs and b- improving the detection of anomalies within live information systems. This new technology will enable the development of a set of new tools to help detect the presence of malware and malicious activity within information systems during operations. Significance to defence and security All the technologies described in this document result from collaborative R&D efforts (the Poly-Tracing project), which involved the participation of NSERC, Ericsson Canada, DRDC – Valcartier Research Centre, and the following Canadian universities: Montreal Polytechnique, Laval University, Concordia University, and the University of Ottawa. This scientific report should be considered as one of the Platform-to-Assembly Secured Systems (PASS) deliverables.
    [Show full text]
  • CS414 SP 2007 Assignment 1
    CS414 SP 2007 Assignment 1 Due Feb. 07 at 11:59pm Submit your assignment using CMS 1. Which of the following should NOT be allowed in user mode? Briefly explain. a) Disable all interrupts. b) Read the time-of-day clock c) Set the time-of-day clock d) Perform a trap e) TSL (test-and-set instruction used for synchronization) Answer: (a), (c) should not be allowed. Which of the following components of a program state are shared across threads in a multi-threaded process ? Briefly explain. a) Register Values b) Heap memory c) Global variables d) Stack memory Answer: (b) and (c) are shared 2. After an interrupt occurs, hardware needs to save its current state (content of registers etc.) before starting the interrupt service routine. One issue is where to save this information. Here are two options: a) Put them in some special purpose internal registers which are exclusively used by interrupt service routine. b) Put them on the stack of the interrupted process. Briefly discuss the problems with above two options. Answer: (a) The problem is that second interrupt might occur while OS is in the middle of handling the first one. OS must prevent the second interrupt from overwriting the internal registers. This strategy leads to long dead times when interrupts are disabled and possibly lost interrupts and lost data. (b) The stack of the interrupted process might be a user stack. The stack pointer may not be legal which would cause a fatal error when the hardware tried to write some word at it.
    [Show full text]
  • Building Embedded Linux Systems ,Roadmap.18084 Page Ii Wednesday, August 6, 2008 9:05 AM
    Building Embedded Linux Systems ,roadmap.18084 Page ii Wednesday, August 6, 2008 9:05 AM Other Linux resources from O’Reilly Related titles Designing Embedded Programming Embedded Hardware Systems Linux Device Drivers Running Linux Linux in a Nutshell Understanding the Linux Linux Network Adminis- Kernel trator’s Guide Linux Books linux.oreilly.com is a complete catalog of O’Reilly’s books on Resource Center Linux and Unix and related technologies, including sample chapters and code examples. ONLamp.com is the premier site for the open source web plat- form: Linux, Apache, MySQL, and either Perl, Python, or PHP. Conferences O’Reilly brings diverse innovators together to nurture the ideas that spark revolutionary industries. We specialize in document- ing the latest tools and systems, translating the innovator’s knowledge into useful skills for those in the trenches. Visit con- ferences.oreilly.com for our upcoming events. Safari Bookshelf (safari.oreilly.com) is the premier online refer- ence library for programmers and IT professionals. Conduct searches across more than 1,000 books. Subscribers can zero in on answers to time-critical questions in a matter of seconds. Read the books on your Bookshelf from cover to cover or sim- ply flip to the page you need. Try it today for free. main.title Page iii Monday, May 19, 2008 11:21 AM SECOND EDITION Building Embedded Linux SystemsTomcat ™ The Definitive Guide Karim Yaghmour, JonJason Masters, Brittain Gilad and Ben-Yossef, Ian F. Darwin and Philippe Gerum Beijing • Cambridge • Farnham • Köln • Sebastopol • Taipei • Tokyo Building Embedded Linux Systems, Second Edition by Karim Yaghmour, Jon Masters, Gilad Ben-Yossef, and Philippe Gerum Copyright © 2008 Karim Yaghmour and Jon Masters.
    [Show full text]
  • Cgroups Py: Using Linux Control Groups and Systemd to Manage CPU Time and Memory
    cgroups py: Using Linux Control Groups and Systemd to Manage CPU Time and Memory Curtis Maves Jason St. John Research Computing Research Computing Purdue University Purdue University West Lafayette, Indiana, USA West Lafayette, Indiana, USA [email protected] [email protected] Abstract—cgroups provide a mechanism to limit user and individual resource. 1 Each directory in a cgroupsfs hierarchy process resource consumption on Linux systems. This paper represents a cgroup. Subdirectories of a directory represent discusses cgroups py, a Python script that runs as a systemd child cgroups of a parent cgroup. Within each directory of service that dynamically throttles users on shared resource systems, such as HPC cluster front-ends. This is done using the the cgroups tree, various files are exposed that allow for cgroups kernel API and systemd. the control of the cgroup from userspace via writes, and the Index Terms—throttling, cgroups, systemd obtainment of statistics about the cgroup via reads [1]. B. Systemd and cgroups I. INTRODUCTION systemd A frequent problem on any shared resource with many users Systemd uses a named cgroup tree (called )—that is that a few users may over consume memory and CPU time. does not impose any resource limits—to manage processes When these resources are exhausted, other users have degraded because it provides a convenient way to organize processes in access to the system. A mechanism is needed to prevent this. a hierarchical structure. At the top of the hierarchy, systemd creates three cgroups By placing throttles on physical memory consumption and [2]: CPU time for each individual user, cgroups py prevents re- source exhaustion on a shared system and ensures continued • system.slice: This contains every non-user systemd access for other users.
    [Show full text]