DOCSLIB.ORG

Exception-Less System Calls for Event-Driven Servers

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Exception-Less System Calls for Event-Driven Servers Exception-Less System Calls for Event-Driven Servers Livio Soares Michael Stumm Department of Electrical and Computer Engineering University of Toronto Abstract sue kernel requests by writing to a reserved syscall page, shared between the application and the kernel, and then Event-driven architectures are currently a popular design switching to another user-level thread ready to execute choice for scalable, high-performance server applications. without having to enter the kernel. On the kernel side, For this reason, operating systems have invested in effi- special in-kernel syscall threads asynchronously execute ciently supporting non-blocking and asynchronous I/O, as the posted system calls obtained from the shared syscall well as scalable event-based notification systems. page, storing the results to the syscall page after their ser- We propose the use of exception-less system calls as vicing. This approach enables flexibility in the scheduling the main operating system mechanism to construct high- of operating system work both in the form of kernel re- performance event-driven server applications. Exception- quest batching, and (in the case of multi-core processors) less system calls have four main advantages over tra- in the form of allowing operating system and application ditional operating system support for event-driven pro- execution to occur on different cores. This not only sig- grams: (1) any system call can be invoked asyn- nificantly reduces the number of costly domain switches, chronously, even system calls that are not file descriptor but also significantly increases temporal and spacial local- based, (2) support in the operating system kernel is non- ity at both user and kernel level, thus reducing pollution intrusive as code changes are not required for each sys- effects on processor structures. tem call, (3) processor efficiency is increased since mode Our implementation of exception-less system calls in switches are mostly avoided when issuing or executing the Linux kernel (FlexSC) was accompanied by a user- asynchronous operations, and (4) enabling multi-core ex- mode POSIX compatible thread package, called FlexSC- ecution for event-driven programs is easier, given that a Threads, that transparently translates legacy synchronous single user-mode execution context can generate enough system calls into exception-less ones. FlexSC-Threads requests to keep multiple processors/cores busy with ker- primarily targets highly threaded server applications, such nel execution. as Apache and MySQL. Experiments demonstrated that We present libflexsc, an asynchronous system call and FlexSC-Threads increased the throughput of Apache by notification library suitable for building event-driven ap- 116% while reducing request latencies by 50%, and in- plications. Libflexsc makes use of exception-less system creased the throughput of MySQL by 40% while reducing calls through our Linux kernel implementation, FlexSC. request latencies by roughly 30%, requiring no changes to We describe the port of two popular event-driven servers, these applications. memcached and nginx, to libflexsc. We show that exception-less system calls increase the throughput of In this paper we report on our subsequent investiga- memcached by up to 35% and nginx by up to 120% as tions on whether exception-less system calls are suitable a result of improved processor efficiency. for event-driven application servers and, if so, whether exception-less system calls are effective in improving throughput and reducing latencies. Event-driven appli- 1 Introduction cation server architectures handle concurrent requests by using just a single thread (or one thread per core) so as to In a previous publication, we introduced the concept of reduce application-level context switching and the mem- exception-less system calls [28]. With exception-less ory footprint that many threads otherwise require. They system calls, instead of issuing system calls in the tradi- make use of non-blocking or asynchronous system calls tional way using a trap (exception) to switch to the ker- to support the concurrent handling of requests. The be- nel for the processing of the system call, applications is- lief that event-driven architectures have superior perfor- ) r mance characteristics is why this architecture has been e 70% t s Indirect widely adopted for developing high-performant and scal- a 60% f Direct s 50% able servers [12, 22, 23, 26, 30]. Widely used applica- i r 40% tion servers with event-driven architectures include mem- e w 30% o cached and nginx. l ( 20% The design and implementation of operating system n o i 10% t support for asynchronous operations, along with event- a 0% d based notification interfaces to support event-driven archi- a 1K 2K 5K 10K 20K 50K 100K r g user-mode instructions between exceptions tectures, has been an active area of both research and de- e D (log scale) velopment [4,8,7, 11, 13, 14, 16, 22, 23, 30]. Most of the proposals have a few common characteristics. First, the Figure 1: System call (pwrite) impact on user-mode instruc- interfaces exposed to user-mode are based on file descrip- tions per cycle (IPC) as a function of system call frequency for tors (with the exception of kqueue [4, 16] and LAIO [11]). Xalan. Consequently, resources that are not encapsulated as de- scriptors (e.g., memory) are not supported. Second, their implementation typically involved significant restructure exploit multiple processors (cores) is to use an operat- of kernel code paths into an asynchronous state-machine ing system visible execution context, be it a thread or in order to avoid blocking the user execution context. a process. With exception-less system calls, however, Third, and most relevant to our work, while the system operating system work can be issued and distributed to calls used to request operating system services are de- multiple remote cores. As an example, in our imple- signed not to block execution, applications still issue sys- mentation of memcached, a single memcached thread tem calls synchronously, raising a processor exception, was sufficient to generate work to fully utilize 4 cores. and switching execution domains, for every request, status Specifically, we describe the design and implementa- check, or notification of completion. tion of an asynchronous system call notification library, In this paper, we demonstrate that the exception-less libflexsc, which is intended to efficiently support event- system call mechanism is well suited for the construction driven programs. To demonstrate the performance ad- of event-based servers and that the exception-less mech- vantages of exception-less system calls for event-driven anism presents several advantages over previous event- servers, we have ported two popular and widely deployed based systems: event-based servers to libflexsc: memcached and nginx. 1. General purpose. Exception-less system call is a gen- We briefly describe the effort in porting these applications eral mechanism that supports any system call and is not to libflexsc. We show how the use of libflexsc can sig- necessarily tied to operations with file descriptors. For nificantly improve the performance of these two servers this reason, exception-less system calls provide asyn- over their original implementation using non-blocking I/O epoll chronous operation on any operating system managed and Linux’s interface. Our experiments demon- resource. strate throughput improvements in memcached of up to 35% and nginx of up to 120%. As anticipated, we show 2. Non-intrusive kernel implementation. Exception- that the performance improvements largely stem from in- less system calls are implemented using light-weight creased efficiency in the use of the underlying processor. kernel threads that can block without affecting user- mode execution. For this reason, kernel code paths do not need to be restructured as asynchronous state- 2 Background and Motivation: Operating machines; in fact, no changes are necessary to the code System Support for I/O Concurrency of standard system calls. Server applications that are required to efficiently han- 3. Efficient user and kernel mode execution. One of dle multiple concurrent requests rely on operating sys- the most significant advantages of exception-less sys- tem primitives that provide I/O concurrency. These prim- tem calls is its ability to decouple system call invoca- itives typically influence the programming model used tion from execution. Invocation of system calls can to implement the server. The two most commonly be done entirely in user-mode, allowing for truly asyn- used models for I/O concurrency are threads and non- chronous execution of user code. As we show in this blocking/asynchronous I/O. paper, this enables significant performance improve- Thread based programming is often considered the sim- ments over the most efficient non-blocking interface on plest, as it does not require tracking the progress of I/O op- Linux. erations (which is done implicitly by the operating system 4. Simpler multi-processing. With traditional system kernel). A disadvantage of threaded servers that utilize a calls, the only mechanism available for applications to separate thread per request/transaction is the inefficiency Server (workload) Syscalls per User Instructions User IPC Kernel Instructions Kernel IPC Request per Syscall per Syscall Memcached (memslap) 2 3750 0.80 5420 0.59 nginx (ApacheBench) 12 1460 0.46 6540 0.49 Table 1: The average number of instructions executed on different workloads before issuing a syscall, the average number of system calls required to satisfy a single request, and the resulting processor efficiency, shown as instructions per cycle (IPC) of both user and kernel execution. Memcached and nginx are event-driven servers using Linux’s epoll interface. of handling a large number of concurrent requests. The facilities, is largely responsible for the low efficiency of two main sources of inefficiency are the extra memory us- user and kernel execution, as quantified by the instruc- age allocated to thread stacks and the overhead of tracking tions per cycle (IPC) metric in Table1.
Load more

Recommended publications
  • A Practical UNIX Capability System
    A Practical UNIX Capability System Adam Langley <[email protected]> 22nd June 2005 ii Abstract This report seeks to document the development of a capability security system based on a Linux kernel and to follow through the implications of such a system. After defining terms, several other capability systems are discussed and found to be excellent, but to have too high a barrier to entry. This motivates the development of the above system. The capability system decomposes traditionally monolithic applications into a number of communicating actors, each of which is a separate process. Actors may only communicate using the capabilities given to them and so the impact of a vulnerability in a given actor can be reasoned about. This design pattern is demonstrated to be advantageous in terms of security, comprehensibility and mod- ularity and with an acceptable performance penality. From this, following through a few of the further avenues which present themselves is the two hours traffic of our stage. Acknowledgments I would like to thank my supervisor, Dr Kelly, for all the time he has put into cajoling and persuading me that the rest of the world might have a trick or two worth learning. Also, I’d like to thank Bryce Wilcox-O’Hearn for introducing me to capabilities many years ago. Contents 1 Introduction 1 2 Terms 3 2.1 POSIX ‘Capabilities’ . 3 2.2 Password Capabilities . 4 3 Motivations 7 3.1 Ambient Authority . 7 3.2 Confused Deputy . 8 3.3 Pervasive Testing . 8 3.4 Clear Auditing of Vulnerabilities . 9 3.5 Easy Configurability .
    [Show full text]
  • Reducing Power Consumption in Mobile Devices by Using a Kernel
    IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. Z, NO. B, AUGUST 2017 1 Reducing Event Latency and Power Consumption in Mobile Devices by Using a Kernel-Level Display Server Stephen Marz, Member, IEEE and Brad Vander Zanden and Wei Gao, Member, IEEE E-mail: [email protected], [email protected], [email protected] Abstract—Mobile devices differ from desktop computers in that they have a limited power source, a battery, and they tend to spend more CPU time on the graphical user interface (GUI). These two facts force us to consider different software approaches in the mobile device kernel that can conserve battery life and reduce latency, which is the duration of time between the inception of an event and the reaction to the event. One area to consider is a software package called the display server. The display server is middleware that handles all GUI activities between an application and the operating system, such as event handling and drawing to the screen. In both desktop and mobile devices, the display server is located in the application layer. However, the kernel layer contains most of the information needed for handling events and drawing graphics, which forces the application-level display server to make a series of system calls in order to coordinate events and to draw graphics. These calls interrupt the CPU which can increase both latency and power consumption, and also require the kernel to maintain event queues that duplicate event queues in the display server. A further drawback of placing the display server in the application layer is that the display server contains most of the information required to efficiently schedule the application and this information is not communicated to existing kernels, meaning that GUI-oriented applications are scheduled less efficiently than they might be, which further increases power consumption.
    [Show full text]
  • Ultimate++ Forum Probably with These Two Variables You Could Try to Integrate D-BUS
    Subject: DBus integration -- need help Posted by jlfranks on Thu, 20 Jul 2017 15:30:07 GMT View Forum Message <> Reply to Message We are trying to add a DBus server to existing large U++ application that runs only on Linux. I've converted from X11 to GTK for Upp project config to be compatible with GIO dbus library. I've created a separate thread for the DBus server and ran into problems with event loop. I've gutted my DBus server code of everything except what is causing an issue. DBus GIO examples use GMainLoop in order for DBus to service asynchronous events. Everything compiles and runs except the main UI is not longer visible. There must be a GTK main loop already running and I've stepped on it with this code. Is there a way for me to obtain a pointer to the UI main loop and use it with my DBus server? How/where can I do that? Code snipped example as follows: ---- code snippet ---- myDBusServerMainThread() { //========================================================== ===== // // Enter main service loop for this thread // while (not needsExit ()) { // colaborate with join() GMainLoop *loop; loop = g_main_loop_new(NULL, FALSE); g_main_loop_run(loop); } } Subject: Re: DBus integration -- need help Posted by Klugier on Thu, 20 Jul 2017 22:30:17 GMT View Forum Message <> Reply to Message Hello, You could try use following methods of Ctrl to obtain gtk & gdk handlers: GdkWindow *gdk() const { return top ? top->window->window : NULL; } GtkWindow *gtk() const { return top ? (GtkWindow *)top->window : NULL; } Page 1 of 3 ---- Generated from Ultimate++ forum Probably with these two variables you could try to integrate D-BUS.
    [Show full text]
  • Fundamentals of Xlib Programming by Examples
    Fundamentals of Xlib Programming by Examples by Ross Maloney Contents 1 Introduction 1 1.1 Critic of the available literature . 1 1.2 The Place of the X Protocol . 1 1.3 X Window Programming gotchas . 2 2 Getting started 4 2.1 Basic Xlib programming steps . 5 2.2 Creating a single window . 5 2.2.1 Open connection to the server . 6 2.2.2 Top-level window . 7 2.2.3 Exercises . 10 2.3 Smallest Xlib program to produce a window . 10 2.3.1 Exercises . 10 2.4 A simple but useful X Window program . 11 2.4.1 Exercises . 12 2.5 A moving window . 12 2.5.1 Exercises . 15 2.6 Parts of windows can disappear from view . 16 2.6.1 Testing overlay services available from an X server . 17 2.6.2 Consequences of no server overlay services . 17 2.6.3 Exercises . 23 2.7 Changing a window’s properties . 23 2.8 Content summary . 25 3 Windows and events produce menus 26 3.1 Colour . 26 3.1.1 Exercises . 27 i CONTENTS 3.2 A button to click . 29 3.3 Events . 33 3.3.1 Exercises . 37 3.4 Menus . 37 3.4.1 Text labelled menu buttons . 38 3.4.2 Exercises . 43 3.5 Some events of the mouse . 44 3.6 A mouse behaviour application . 55 3.6.1 Exercises . 58 3.7 Implementing hierarchical menus . 58 3.7.1 Exercises . 67 3.8 Content summary . 67 4 Pixmaps 68 4.1 The pixmap resource .
    [Show full text]
  • Onload User Guide
    Onload User Guide Copyright © 2017 SOLARFLARE Communications, Inc. All rights reserved. The software and hardware as applicable (the “Product”) described in this document, and this document, are protected by copyright laws, patents and other intellectual property laws and international treaties. The Product described in this document is provided pursuant to a license agreement, evaluation agreement and/or non‐disclosure agreement. The Product may be used only in accordance with the terms of such agreement. The software as applicable may be copied only in accordance with the terms of such agreement. Onload is licensed under the GNU General Public License (Version 2, June 1991). See the LICENSE file in the distribution for details. The Onload Extensions Stub Library is Copyright licensed under the BSD 2‐Clause License. Onload contains algorithms and uses hardware interface techniques which are subject to Solarflare Communications Inc patent applications. Parties interested in licensing Solarflare's IP are encouraged to contact Solarflare's Intellectual Property Licensing Group at: Director of Intellectual Property Licensing Intellectual Property Licensing Group Solarflare Communications Inc, 7505 Irvine Center Drive Suite 100 Irvine, California 92618 You will not disclose to a third party the results of any performance tests carried out using Onload or EnterpriseOnload without the prior written consent of Solarflare. The furnishing of this document to you does not give you any rights or licenses, express or implied, by estoppel or otherwise, with respect to any such Product, or any copyrights, patents or other intellectual property rights covering such Product, and this document does not contain or represent any commitment of any kind on the part of SOLARFLARE Communications, Inc.
    [Show full text]
  • Programmer's Guide
    Programmer’s Guide Release 18.11.11 Jan 20, 2021 CONTENTS 1 Introduction 1 1.1 Documentation Roadmap...............................1 1.2 Related Publications..................................2 2 Overview 3 2.1 Development Environment..............................3 2.2 Environment Abstraction Layer............................4 2.3 Core Components...................................4 2.3.1 Ring Manager (librte_ring)..........................4 2.3.2 Memory Pool Manager (librte_mempool)..................4 2.3.3 Network Packet Buffer Management (librte_mbuf).............6 2.3.4 Timer Manager (librte_timer)........................6 2.4 Ethernet* Poll Mode Driver Architecture.......................6 2.5 Packet Forwarding Algorithm Support........................6 2.6 librte_net........................................6 3 Environment Abstraction Layer7 3.1 EAL in a Linux-userland Execution Environment..................7 3.1.1 Initialization and Core Launching......................8 3.1.2 Shutdown and Cleanup...........................8 3.1.3 Multi-process Support............................8 3.1.4 Memory Mapping Discovery and Memory Reservation..........8 3.1.5 Support for Externally Allocated Memory.................. 11 3.1.6 Per-lcore and Shared Variables....................... 12 3.1.7 Logs...................................... 12 3.1.8 CPU Feature Identification.......................... 12 3.1.9 User Space Interrupt Event......................... 13 3.1.10 Blacklisting.................................. 14 3.1.11 Misc Functions...............................
    [Show full text]
  • A Linux Kernel Scheduler Extension for Multi-Core Systems
    A Linux Kernel Scheduler Extension For Multi-Core Systems Aleix Roca Nonell Master in Innovation and Research in Informatics (MIRI) specialized in High Performance Computing (HPC) Facultat d’informàtica de Barcelona (FIB) Universitat Politècnica de Catalunya Supervisor: Vicenç Beltran Querol Cosupervisor: Eduard Ayguadé Parra Presentation date: 25 October 2017 Abstract The Linux Kernel OS is a black box from the user-space point of view. In most cases, this is not a problem. However, for parallel high performance computing applications it can be a limitation. Such applications usually execute on top of a runtime system, itself executing on top of a general purpose kernel. Current runtime systems take care of getting the most of each system core by distributing work among the multiple CPUs of a machine but they are not aware of when one of their threads perform blocking calls (e.g. I/O operations). When such a blocking call happens, the processing core is stalled, leading to performance loss. In this thesis, it is presented the proof-of-concept of a Linux kernel extension denoted User Monitored Threads (UMT). The extension allows a user-space application to be notified of the blocking and unblocking of its threads, making it possible for a core to execute another worker thread while the other is blocked. An existing runtime system (namely Nanos6) is adapted, so that it takes advantage of the kernel extension. The whole prototype is tested on a synthetic benchmarks and an industry mock-up application. The analysis of the results shows, on the tested hardware and the appropriate conditions, a significant speedup improvement.
    [Show full text]
  • Linux Kernel Development 3Rd Edition
    ptg Linux Kernel Development Third Edition ptg From the Library of Wow! eBook Developer’s Library ESSENTIAL REFERENCES FOR PROGRAMMING PROFESSIONALS Developer’s Library books are designed to provide practicing programmers with unique, high-quality references and tutorials on the programming languages and technologies they use in their daily work. All books in the Developer’s Library are written by expert technology practitioners who are especially skilled at organizing and presenting information in a way that’s useful for other programmers. Key titles include some of the best, most widely acclaimed books within their topic areas: PHP & MySQL Web Development Python Essential Reference Luke Welling & Laura Thomson David Beazley ISBN 978-0-672-32916-6 ISBN-13: 978-0-672-32978-6 MySQL Programming in Objective-C 2.0 ptg Paul DuBois Stephen G. Kochan ISBN-13: 978-0-672-32938-8 ISBN-13: 978-0-321-56615-7 Linux Kernel Development PostgreSQL Robert Love Korry Douglas ISBN-13: 978-0-672-32946-3 ISBN-13: 978-0-672-33015-5 Developer’s Library books are available at most retail and online bookstores, as well as by subscription from Safari Books Online at safari.informit.com Developer’s Library informit.com/devlibrary From the Library of Wow! eBook Linux Kernel Development ptg Third Edition Robert Love Upper Saddle River, NJ • Boston • Indianapolis • San Francisco New York • Toronto • Montreal • London • Munich • Paris • Madrid Cape Town • Sydney • Tokyo • Singapore • Mexico City From the Library of Wow! eBook Linux Kernel Development Acquisitions Editor Third Edition Mark Taber Development Copyright © 2010 Pearson Education, Inc.
    [Show full text]
  • ODROID-HC2: 3.5” High Powered Storage  February 1, 2018
    ODROID WiFi Access Point: Share Files Via Samba February 1, 2018 How to setup an ODROID with a WiFi access point so that an ODROID’s hard drive can be accessed and modied from another computer. This is primarily aimed at allowing access to images, videos, and log les on the ODROID. ODROID-HC2: 3.5” High powered storage February 1, 2018 The ODROID-HC2 is an aordable mini PC and perfect solution for a network attached storage (NAS) server. This device home cloud-server capabilities centralizes data and enables users to share and stream multimedia les to phones, tablets, and other devices across a network. It is an ideal tool for many use Using SquashFS As A Read-Only Root File System February 1, 2018 This guide describes the usage of SquashFS PiFace: Control and Display 2 February 1, 2018 For those who have the PiFace Control and Display 2, and want to make it compatible with the ODROID-C2 Android Gaming: Data Wing, Space Frontier, and Retro Shooting – Pixel Space Shooter February 1, 2018 Variations on a theme! Race, blast into space, and blast things into pieces that are racing towards us. The fun doesn’t need to stop when you take a break from your projects. Our monthly pick on Android games. Linux Gaming: Saturn Games – Part 1 February 1, 2018 I think it’s time we go into a bit more detail about Sega Saturn for the ODROID-XU3/XU4 Gaming Console: Running Your Favorite Games On An ODROID-C2 Using Android February 1, 2018 I built a gaming console using an ODROID-C2 running Android 6 Controller Area Network (CAN) Bus: Implementation
    [Show full text]
  • Introduction to Asynchronous Programming
    Introduction to Asynchronous Programming In this document we introduce an asynchronous model for concurrent programming. For certain appli- cations, an asynchronous model may yield performance benefits over traditional multithreading. Much of the material presented in this document is taken from Dave Peticola’s excellent introduction to Twisted1, a Python framework for asynchronous programming. 1 The Models We will start by reviewing two (hopefully) familiar models in order to contrast them with the asynchronous model. By way of illustration we will imagine a program that consists of three conceptually distinct tasks which must be performed to complete the program. Note I am using task in the non-technical sense of something that needs to be done. The first model we will look at is the single-threaded synchronous model, in Figure 1 below: Figure 1: The single-threaded synchronous model This is the simplest style of programming. Each task is performed one at a time, with one finishing completely before another is started. And if the tasks are always performed in a definite order, the imple- mentation of a later task can assume that all earlier tasks have finished without errors, with all their output available for use — a definite simplification in logic. We can contrast the single-threaded synchronous model with the multi-threaded synchronous model illustrated in Figure 2. In this model, each task is performed in a separate thread of control. The threads are managed by the operating system and may, on a system with multiple processors or multiple cores, run truly concurrently, 1http://krondo.com/?page_id=1327 1 CS168 Async Programming Figure 2: The threaded model or may be interleaved together on a single processor.
    [Show full text]
  • Monitoring File Events
    MONITORING FILE EVENTS Some applications need to be able to monitor files or directories in order to deter- mine whether events have occurred for the monitored objects. For example, a graphical file manager needs to be able to determine when files are added or removed from the directory that is currently being displayed, or a daemon may want to monitor its configuration file in order to know if the file has been changed. Starting with kernel 2.6.13, Linux provides the inotify mechanism, which allows an application to monitor file events. This chapter describes the use of inotify. The inotify mechanism replaces an older mechanism, dnotify, which provided a subset of the functionality of inotify. We describe dnotify briefly at the end of this chapter, focusing on why inotify is better. The inotify and dnotify mechanisms are Linux-specific. (A few other systems provide similar mechanisms. For example, the BSDs provide the kqueue API.) A few libraries provide an API that is more abstract and portable than inotify and dnotify. The use of these libraries may be preferable for some applications. Some of these libraries employ inotify or dnotify, on systems where they are available. Two such libraries are FAM (File Alteration Monitor, http:// oss.sgi.com/projects/fam/) and Gamin (http://www.gnome.org/~veillard/gamin/). 19.1 Overview The key steps in the use of the inotify API are as follows: 1. The application uses inotify_init() to create an inotify instance. This system call returns a file descriptor that is used to refer to the inotify instance in later operations.
    [Show full text]
  • Unbreakable Enterprise Kernel Release Notes for Unbreakable Enterprise Kernel Release 3
    Unbreakable Enterprise Kernel Release Notes for Unbreakable Enterprise Kernel Release 3 E48380-10 June 2020 Oracle Legal Notices Copyright © 2013, 2020, Oracle and/or its affiliates. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software" or "commercial computer software documentation" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract.
    [Show full text]