Академический Документы
Профессиональный Документы
Культура Документы
About Me
Ph.D. in Computer Engineering (Operating Systems
universities http://microsoft.com/WindowsAcademic or compsci@microsoft.com Wrote the Windows material for leading OS textbooks
Tanenbaum, Silberschatz, Stallings
Effect on OS Design
NT vs UNIX
Although both Windows and Linux have adapted to changes in the environment, the original design environments (i.e. in 1989 and 1969) heavily influenced the design choices: Unit of concurrency: Process creation: I/O: Namespace root: Security: Threads vs processes CreateProcess() vs fork() Async vs sync Virtual vs Filesystem ACLs vs uid/gid Addr space, uniproc Addr space, swapping Swapping, I/O devices Removable storage User populations
Windows Architecture
System Processes Service Control Mgr. LSASS WinLogon User Mode Session Manager SvcHost.Exe WinMgt.Exe SpoolSv.Exe Services.Exe Task Manager Explorer User Application POSIX Subsystem DLLs Services Applications
OS/2
Windows DLLs
NTDLL.DLL
System Service Dispatcher (kernel mode callable interfaces) I/O Mgr Configuration Mgr (registry) Local Procedure Call Security Reference Monitor Processes & Threads Plug and Play Mgr. Virtual Memory File System Cache Object Mgr. Power Mgr. Windows USER, GDI
Graphics Drivers
Kernel Hardware Abstraction Layer (HAL) hardware interfaces (buses, I/O devices, interrupts, interval timers, DMA, memory cache control, etc., etc.)
Kernel-mode Architecture of user Windows mode NT API stubs (wrap sysenter) -- system library (ntdll.dll)
NTOS kernel layer Trap/Exception/Interrupt Dispatch CPU mgmt: scheduling, synchr, ISRs/DPCs/APCs
kerne l mode
Hardware Abstraction Layer (HAL): BIOS/chipset details firmwar e/ CPU, MMU, APIC, BIOS/ACPI, memory, devices Copyright Microsoft Corporation hardwar
Kernel/Executive layers
Kernel layer ntos/ke ~ 5% of NTOS
source) Abstracts the CPU
Threads, Asynchronous Procedure Calls (APCs) Interrupt Service Routines (ISRs) Deferred Procedure Calls (DPCs aka Software Interrupts)
Executive layer
OS Services running in a multithreaded
Change how Windows is built Lots of DLL refactoring API Sets (virtual DLLs) Working-set management
Runaway processes quickly start reusing own pages Break up kernel working-set into multiple working-sets
System cache, paged pool, pageable system code
Security Better UAC, new account types, less BitLocker blockers Energy efficiency Trigger-started background services Core Parking Timer-coalescing, tick skipping
server apps
MinWin
MinWin is first step at creating
architectural partitions
rest of the system Higher layers can evolve independently An engineering process improvement, not a microkernel NT!
drivers, services No servicing, WMI, graphics, audio or shell, etc, etc, etc
MinWin footprint:
MinWin Layering
Shell, Graphics, Multimedia, Layered Services, Applets, Etc.
Timer Coalescing
Secret of energy efficiency: Go idle and Stay idle Staying idle requires minimizing timer interrupts Before, periodic timers had independent cycles even
when period was the same New timer APIs permit timer coalescing
Application or driver specifies tolerable delay Timer system shifts timer firing
MarkRuss
workloads Lock protects all thread state changes (wait, unwait) Very lock at >64x Dispatcher lock broken up in Windows 7 / Server 2008 R2 Each object protected by its own lock Many operations are lock-free
Broke apart the Dispatcher Lock Dispatcher lock hottest on server Scheduler
memory In use: in working sets: Not assigned: on paging lists: freemodified, standby, Before, all page state changes protected by global PFN (Physical Frame Number) lock As of Windows 7 the PFN lock is gone Pages are now locked individually Improves scalability for large memory applications
Bad News:
Power is about as low as it can go Logic paths between clocked elements are pretty short
Good News:
Moores Law continues (# transistors doubles ~22 months) All that parallel computational theory is going into practice Transistors going into more cores, not faster cores!
Extend with private (or shared) SIMD engines (SSE on steroids) (Maybe) not very energy efficient
A few more big, cores and lots of smaller, slower, cooler cores
Use SIMD for performance Shutoff idle small cores for energy efficiency (but leakage?) Nobody has ever gotten this to work more on this later
Heterogeneous
Programmable Accelerators (e.g. GPUs)
Fixed-function Accelerators
Could have extra threads, but then kernel and usermode are competing to schedule the CPU
Run-Time)
crossing KT switch is lazy: at kernel entry (e.g. syscall, pagefault) CPU returned to user-mode scheduler when KT blocks
completion
Normal NT Threading
Kernel-mode Scheduler KT0 kerne l user KT1 trap code UT0 UT1 UT2 KT2 x86 core NTOS executive
NT Thread is Kernel Thread (KT) and User Thread (UT) UT/KT form a single logical thread representing NT thread in user or kernel KT: ETHREAD, KSTACK, link to EPROCESS UT: TEB, USTACK
KT1
KT2
UT0
UT1
UT0
UMS
Based on NT threads
(Well, sort of)
Each NT thread has user & kernel parts (UT & KT) When a thread becomes UMS, KT never returns to UT Instead, the primary thread calls the USched
USched
When a UT enters kernel and blocks, the primary thread will hand CPU back to the USched declaring UT blocked When UT unblocks, kernel queues notification USched consumes notifications, marks UT runnable
Primary Thread
So UTs can migrate between threads Affinities of primaries and KTs are orthogonal issues
Copyright Microsoft Corporation
enter the USched world and become primaries, primaries also can be created by UScheds to allow parallel execution
Primaries represent concurrent execution
kernel
MarkRuss
I/O is queued to thread Mutexes record thread owner Impersonation Cross-thread operations expect to find threads and IDs Win32 code has thread and affinity awareness
Copyright Microsoft Corporation
KT0
KT1
KT2
Thread Parking
Syscall Request Queue Syscall Completion Queue UT0 Remote Scheduler UT2 Remote x86
UTs (can) run on accelerators or x86s Pagefaults are just like syscalls
UT1
Amdahls Law overtakes Moores Law as highorder bit Heterogeneous cores? OS Scalability Loosely coupled OS: mem + cpu + services? Energy efficiency Shrink-wrap and Freeze-dry applications? Hypervisor/Kernel/Runtime relationships Move kernel scheduling (cpu/memory) into runtimes? Move kernel resource management into Hypervisor? Copyright Microsoft Corporation
MS Academic Groups
muchas gracias
30