From owner-freebsd-hackers Fri Jul 5 13:07:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA05925 for hackers-outgoing; Fri, 5 Jul 1996 13:07:01 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA05920 for ; Fri, 5 Jul 1996 13:06:56 -0700 (PDT) Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id QAA09584; Fri, 5 Jul 1996 16:00:40 -0400 (EDT) Received: from netrix.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA07819; Fri, 5 Jul 1996 16:00:39 -0400 Received: from localhost by netrix.lkg.dec.com; (5.65v3.2/1.1.8.2/28May95-0415PM) id AA11110; Fri, 5 Jul 1996 16:00:52 -0400 Message-Id: <9607052000.AA11110@netrix.lkg.dec.com> To: tech-kern@netbsd.org, freebsd-hackers@freebsd.org Subject: Some interesting papers on BSD ... Date: Fri, 05 Jul 96 16:00:52 -0400 From: Matt Thomas X-Mts: smtp Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk While for something else, I ran across these 3 papers... ftp://deas-ftp.harvard.edu/techreports/tr-31-95.ps.gz TR-31-95 [tr-31-95.ps.gz (61 K)] Christopher Small and Margo Seltzer. 1995. ``Scheduler Activations on BSD: Sharing Thread Management Between Kernel and Application.'' There are two commonly used thread models: kernel level threads and user level threads. Kernel level threads suffer from the cost of frequent user-kernel domain crossings and fixed kernel scheduling priorities. User level threads are not integrated with the kernel, blocking all threads whenever one thread is blocked. The Scheduler Activations model, proposed by Anderson et al., combines kernel CPU allocation decisions with application control over thread scheduling. This paper discusses the performance characteristics of an implementation of Scheduler Activations for a uniprocessor BSD system, and proposes an analytic model for determining the class of applications that benefit from its use. Our implementation required fewer than two hundred lines of kernel code and provides an order of magnitude performance improvement over process-level facilities. ftp://deas-ftp.harvard.edu/techreports/tr-19-95.ps.gz TR-19-95 [tr-19-95.ps.gz (541 K)] Diane L. Tang. 1995. ``Benchmarking Filesystems.'' One of the most widely researched areas in operating systems is filesystem design, implementation, and performance. Almost all of the research involves reporting performance numbers gathered from a variety of different benchmarks. The problem with such results is that existing filesystem benchmarks are inadequate, suffering from problems ranging from not scaling with advancing technology to not measuring the filesystem. A new approach to filesystem benchmarking is presented here. This methodology is designed both to help system designers understand and improve existing systems and to help users decide which filesystem to buy or run. For usability, the benchmark is separated into two parts: a suite of micro-benchmarks, which is actually run on the filesystem, and a workload characterizer. The results from the two separate parts can be combined to predict the performance of the filesystem on the workload. The purpose for this separation of functionality is two-fold. First, many system designers would like their filesystem to perform well under diverse workloads: by characterizing the workload independently, the designers can better understand what is required of the filesystem. The micro-benchmarks tell the designer what needs to be improved while the workload characterizer tells the designer whether that improvement will affect filesystem performance under that workload. This separation also helps users trying to decide which system to run or buy, who may not be able to run their workload on all systems under consideration, and therefore need this separation. The implementation of this methodology does not suffer from many of the problems seen in existing benchmarks: it scales with technology, it is tightly specified, and it helps system designers. This benchmark's only drawbacks are that it does not accurately predict the performance of a filesystem on a workload, thus limiting its applicability: it is useful to system designers, but not for users trying to decide which system to buy. The belief is that the general approach will work, given additional time to manipulate the prediction algorithm. ftp://deas-ftp.harvard.edu/techreports/tr-09-95.ps.gz TR-09-95 [tr-09-95.ps.gz (77 K)] J. Bradley Chen, Yasuhiro Endo, Kee Chan, David Mazieres, Antonio Dias, Margo Seltzer, and Michael Smith. 1995. ``The Impact of Operating System Structure on Personal Computer Performance.'' This paper presents a comparative study of the performance of three operating systems that run on the personal computer architecture derived from the IBM-PC. The operating systems, Windows for Workgroups (tm), Windows NT (tm), and NetBSD (a freely available UNIX (tm) variant) cover a broad range of system functionality and user requirements, from a single address space model to full protection with preemptive multitasking. Our measurements were enabled by hardware counters in Intel's Pentium (tm) processor that permit measurement of a broad range of processor events including instruction counts and on-chip cache miss rates. We used both microbenchmarks, which expose specific differences between the systems, and application workloads, which provide an indication of expected end-to-end performance. Our microbenchmark results show that accessing system functionality is more expensive in Windows than in the other two systems due to frequent changes in machine mode and the use of system call hooks. When running native applications, Windows NT is more efficient than Windows, but it does incur overhead from its microkernel structure. Overall, system functionality can be accessed most efficiently in NetBSD; we attribute this to its monolithic structure, and to the absence of the complications created by backwards compatibility in the other sys tems. Measurements of application performance show that the impact of these differences is significant in terms of overall execution time. -- Matt Thomas Internet: matt@3am-software.com 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt.html Westford, MA Disclaimer: I disavow all knowledge of this message