Business Life Path - Red Hat, CFS roadmap

Transcription

1 The Kernel Report Vision 2007 edition Jonathan Corbet LWN.net

2 The Plan 1) A very brief history overview 2) The development process 3) Guesses about the future

3 History 1

4 An extremely rushed history of the Linux kernel 0.01 September, March, March, June, January, January, December, 2003

5 October 27, January 2, March 19, June 17, September 19, November 29, February 4, April 21, July 8, October 9, 2007

6 The process 2

7 The release cycle

8 The release cycle

9

10 Who does this work?

11 Who does this work

12 Who does this work Since (September 19, 2006): 29,000 changesets total Over 2 million lines of code changed Patches accepted from 1939 developers Only 11 contributed >= 1% of patches Largest contributor: 717 changesets 2.5% of the total

13 Who funds this work Unknown 20% Red Hat 13% Hobbyists 9% IBM 9% Novell 7% Intel 4% Oracle 3% Google 2% Linux Found. 2% Consultants 2% MIPS Tech. 2% SGI 2% Renesas Tech 2% Astaro 1% HP 1% SWSoft 1% MontaVista 1% Linux Networx 1% Qlogic 1% Qumranet 1%

14 3 What's coming #i ncl ude <di s cl ai mer. h>

15 The next kernel (yesterday!) Features CFS process scheduler ext4 enhancements Xen Lguest Memory fragmentation avoidance User-space driver framework Japanese and Chinese doc translations

16 Around the end of the year x86_64/i386 merger CFS group scheduling Tracing improvements Containers support...?

17 Scalability

18 Scalability Today's supercomputer is tomorrow's laptop.

19 The leading edge 1024 processors works well 4096 still needs some work Highly-contended locks Per-CPU data structures SLUB allocator

20 The other side of scalability Small and embedded systems Reduce data structures Eliminate unneeded subsystems Good power management... Needed: more participation.

21 Filesystems Disks are getting larger But not faster Use of flash storage is increasing Linux filesystems are getting old

22 The fsck problem Whole-disk read time is increasing -> filesystem check time increasing

23 Fixing fsck chunkfs / tilefs Subdivide filesystems Only check parts that were in use

24 Btrfs A completely new filesystem Extent-based Subvolumes and snapshotting Checksumming Online fsck possible Offline fsck fast by design

25 ext4 The successor to ext3 Features 48-bit block numbers Extents Nanosecond time stamps Pre-allocation / delayed allocation Journal checksums Online defragmentation

26 Reiser4 The successor to reiserfs Features Improved performance Low-level plugins Filesystem-as-database Status: stalled Needs a new champion

27 LogFS A new flash-oriented filesystem Features On-media directory tree Wandering tree log structure Strong performance

28 Virtualization Running independent systems as guests High-reliability systems Server consolidation Security Not just a way of extracting money from venture capitalists

29 Virtualization options In the kernel now: Xen Lguest KVM Virtualization is a solved problem...on the kernel side

30 Containers Lightweight virtualization All guests share the host kernel Several projects going

31 Supporting containers Containers complicate the code Indirection for all global resources Processes Devices Filesystems System time Resource management needed too

32 Supporting containers Multiple container APIs won't fly Projects must work together...and they are working together Coming soon: Control groups PID namespaces Network namespaces

33 CPU scheduling Once it seemed like a solved problem...

34 CFS The Completely Fair Scheduler Dump complex interactivity heuristics Use a simpler fairness algorithm Merged in Group scheduling still to come

35 Threadlets Asynchronous system calls If a system call blocks Continue in a new thread Collect the results later

36 Real time Hard real time! Much of this work already merged Mutexes Priority inheritance High-resolution timers Tickless kernel

37 Real time what's left Dynamic tick For other architectures x86_64 Full tickless operation Sleeping spinlocks Interrupt handlers in threads

38 Hardware support Linux supports more hardware than any other system ever has

39 Wireless networking The mac80211 stack has been merged (Formerly Devicescape) Drivers are a little slower Various open issues Regulatory compliance

40 Wireless drivers Great support for many adapters Biggest gap: Atheros...and it's in the works ath5k driver in -mm now

41 Video drivers The biggest remaining problem area Intel: supported Nvidia: not supported nouveau.freedesktop.org ATI: R200, R300 well supported Reverse-engineered R500 driver out ATI is releasing specs!

42 What about the closed-source drivers?

43 Closed-source drivers...are buggier

44 Closed-source drivers...limit our choices

45 Closed-source drivers...cannot be supported

46 Closed-source drivers...do not give back to the kernel

47 Closed-source drivers...can slow kernel development

48 Closed-source drivers...are of questionable legality

49 Closed-source drivers...threaten our free operating system.

50 Power management Lots of hardware hassles Many issues in user space Things are getting better Tickless kernel Drivers being fixed Power top (linuxpowertop.org)

51 Dtrace envy Tracing

52 Tracing SystemTap Everything Dtrace can do Painful to use Kernel markers Place static tracepoints in the kernel Hellwig-approved maybe

53 Security SELinux The default solution Extreme complexity

54 Alternatives to SELinux AppArmor SMACK TOMOYO Linux

55 Participation It works best when everybody joins in

56 Participation It's hard for some companies Interfacing with community is challenging Benefits not always clear

57 Participation It's hard for some cultures Working in English Different modes of interaction

58 GPLv3 It's official Relatively unpopular in kernel circles The kernel is explicitly GPLv2 A change to GPLv3 would be difficult

59 Questions?

60 Kernel releases are... Fast! New kernels every 2-3 months

61 Kernel releases are... Major Every release has Major new features Internal API changes

62 Kernel releases are... Predictable Expect around October

63 Who oversees this work Non-author signoffs since : Google 23% Red Hat 21% Novell 13% unknown 7% IBM 7% hobbyists 6% Linux Foundation 5% Intel 3% SteelEye 3% Cisco 2% MIPS Technologies 2%

64 What the process does well Predictable release cycles Expect around October

65 What the process does well Quickly moves changes to users

66 What the process does well Keeps distributors closer to the mainline

67 What the process does well Excellent tracking and merging of patches

68 What doesn't work so well

69 What doesn't work so well The overall quality of is pretty horrific. -- Dave Jones, Fedora kernel maintainer

70 What doesn't work so well Jobs nobody wants to do Bug tracking Documentation Fixing really difficult bugs

71 What's being done Better bug tracking Stabilization releases Automated testing