diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/CodingStyle | 2 | ||||
| -rw-r--r-- | Documentation/DocBook/.gitignore | 6 | ||||
| -rw-r--r-- | Documentation/DocBook/kernel-api.tmpl | 5 | ||||
| -rw-r--r-- | Documentation/applying-patches.txt | 56 | ||||
| -rw-r--r-- | Documentation/cpusets.txt | 4 | ||||
| -rw-r--r-- | Documentation/filesystems/ext3.txt | 182 | ||||
| -rw-r--r-- | Documentation/hrtimers.txt | 178 | ||||
| -rw-r--r-- | Documentation/kbuild/makefiles.txt | 4 | ||||
| -rw-r--r-- | Documentation/kdump/gdbmacros.txt | 22 | ||||
| -rw-r--r-- | Documentation/kdump/kdump.txt | 149 | ||||
| -rw-r--r-- | Documentation/kernel-parameters.txt | 52 | ||||
| -rw-r--r-- | Documentation/laptop-mode.txt | 6 | ||||
| -rw-r--r-- | Documentation/locks.txt | 17 | ||||
| -rw-r--r-- | Documentation/oops-tracing.txt | 8 | ||||
| -rw-r--r-- | Documentation/stable_kernel_rules.txt | 60 | ||||
| -rw-r--r-- | Documentation/video4linux/CARDLIST.bttv | 1 | ||||
| -rw-r--r-- | Documentation/video4linux/CARDLIST.cx88 | 2 | ||||
| -rw-r--r-- | Documentation/x86_64/boot-options.txt | 2 | ||||
| -rw-r--r-- | Documentation/x86_64/cpu-hotplug-spec | 21 |
19 files changed, 526 insertions, 251 deletions
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index ce780ef..ce5d2c0 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -199,7 +199,7 @@ The rationale is: modifications are prevented - saves the compiler work to optimize redundant code away ;) -int fun(int ) +int fun(int a) { int result = 0; char *buffer = kmalloc(SIZE); diff --git a/Documentation/DocBook/.gitignore b/Documentation/DocBook/.gitignore new file mode 100644 index 0000000..c102c02 --- /dev/null +++ b/Documentation/DocBook/.gitignore @@ -0,0 +1,6 @@ +*.xml +*.ps +*.pdf +*.html +*.9.gz +*.9 diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index 3c47a3f..8c9c670 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl @@ -54,6 +54,11 @@ !Ekernel/sched.c !Ekernel/timer.c </sect1> + <sect1><title>High-resolution timers</title> +!Iinclude/linux/ktime.h +!Iinclude/linux/hrtimer.h +!Ekernel/hrtimer.c + </sect1> <sect1><title>Internal Functions</title> !Ikernel/exit.c !Ikernel/signal.c diff --git a/Documentation/applying-patches.txt b/Documentation/applying-patches.txt index 05a08c2..a083ba3 100644 --- a/Documentation/applying-patches.txt +++ b/Documentation/applying-patches.txt @@ -3,8 +3,7 @@ ------------------------------------ Original by: Jesper Juhl, August 2005 - Last update: 2005-12-02 - + Last update: 2006-01-05 A frequently asked question on the Linux Kernel Mailing List is how to apply @@ -77,7 +76,7 @@ instead: If you wish to uncompress the patch file by hand first before applying it (what I assume you've done in the examples below), then you simply run -gunzip or bunzip2 on the file - like this: +gunzip or bunzip2 on the file -- like this: gunzip patch-x.y.z.gz bunzip2 patch-x.y.z.bz2 @@ -95,7 +94,7 @@ Common errors when patching --- When patch applies a patch file it attempts to verify the sanity of the file in different ways. -Checking that the file looks like a valid patch file, checking the code +Checking that the file looks like a valid patch file & checking the code around the bits being modified matches the context provided in the patch are just two of the basic sanity checks patch does. @@ -122,7 +121,7 @@ outright and leaves a file with a .rej extension (a reject file). You can read this file to see exactly what change couldn't be applied, so you can go fix it up by hand if you wish. -If you don't have any third party patches applied to your kernel source, but +If you don't have any third-party patches applied to your kernel source, but only patches from kernel.org and you apply the patches in the correct order, and have made no modifications yourself to the source files, then you should never see a fuzz or reject message from patch. If you do see such messages @@ -137,7 +136,7 @@ If patch stops and presents a "File to patch:" prompt, then patch could not find a file to be patched. Most likely you forgot to specify -p1 or you are in the wrong directory. Less often, you'll find patches that need to be applied with -p0 instead of -p1 (reading the patch file should reveal if -this is the case - if so, then this is an error by the person who created +this is the case -- if so, then this is an error by the person who created the patch but is not fatal). If you get "Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines)." or a @@ -168,13 +167,17 @@ the patch will in fact apply it. A message similar to "patch: **** unexpected end of file in patch" or "patch unexpectedly ends in middle of line" means that patch could make no sense of -the file you fed to it. Either your download is broken or you tried to feed -patch a compressed patch file without uncompressing it first. +the file you fed to it. Either your download is broken, you tried to feed +patch a compressed patch file without uncompressing it first, or the patch +file that you are using has been mangled by a mail client or mail transfer +agent along the way somewhere, e.g., by splitting a long line into two lines. +Often these warnings can easily be fixed by joining (concatenating) the +two lines that had been split. As I already mentioned above, these errors should never happen if you apply a patch from kernel.org to the correct version of an unmodified source tree. So if you get these errors with kernel.org patches then you should probably -assume that either your patch file or your tree is broken and I'd advice you +assume that either your patch file or your tree is broken and I'd advise you to start over with a fresh download of a full kernel tree and the patch you wish to apply. @@ -200,10 +203,10 @@ do the additional steps since interdiff can get things wrong in some cases. Another alternative is `ketchup', which is a python script for automatic downloading and applying of patches (http://www.selenic.com/ketchup/). - Other nice tools are diffstat which shows a summary of changes made by a -patch, lsdiff which displays a short listing of affected files in a patch -file, along with (optionally) the line numbers of the start of each patch -and grepdiff which displays a list of the files modified by a patch where + Other nice tools are diffstat, which shows a summary of changes made by a +patch; lsdiff, which displays a short listing of affected files in a patch +file, along with (optionally) the line numbers of the start of each patch; +and grepdiff, which displays a list of the files modified by a patch where the patch contains a given regular expression. @@ -228,8 +231,8 @@ The -mm kernels live at In place of ftp.kernel.org you can use ftp.cc.kernel.org, where cc is a country code. This way you'll be downloading from a mirror site that's most likely geographically closer to you, resulting in faster downloads for you, -less bandwidth used globally and less load on the main kernel.org servers - -these are good things, do use mirrors when possible. +less bandwidth used globally and less load on the main kernel.org servers -- +these are good things, so do use mirrors when possible. The 2.6.x kernels @@ -237,14 +240,14 @@ The 2.6.x kernels These are the base stable releases released by Linus. The highest numbered release is the most recent. -If regressions or other serious flaws are found then a -stable fix patch +If regressions or other serious flaws are found, then a -stable fix patch will be released (see below) on top of this base. Once a new 2.6.x base kernel is released, a patch is made available that is a delta between the previous 2.6.x kernel and the new one. -To apply a patch moving from 2.6.11 to 2.6.12 you'd do the following (note +To apply a patch moving from 2.6.11 to 2.6.12, you'd do the following (note that such patches do *NOT* apply on top of 2.6.x.y kernels but on top of the -base 2.6.x kernel - if you need to move from 2.6.x.y to 2.6.x+1 you need to +base 2.6.x kernel -- if you need to move from 2.6.x.y to 2.6.x+1 you need to first revert the 2.6.x.y patch). Here are some examples: @@ -266,7 +269,7 @@ $ mv linux-2.6.11.1 linux-2.6.12 # rename source dir The 2.6.x.y kernels --- - Kernels with 4 digit versions are -stable kernels. They contain small(ish) + Kernels with 4-digit versions are -stable kernels. They contain small(ish) critical fixes for security problems or significant regressions discovered in a given 2.6.x kernel. @@ -277,9 +280,14 @@ versions. If no 2.6.x.y kernel is available, then the highest numbered 2.6.x kernel is the current stable kernel. + note: the -stable team usually do make incremental patches available as well + as patches against the latest mainline release, but I only cover the + non-incremental ones below. The incremental ones can be found at + ftp://ftp.kernel.org/pub/linux/kernel/v2.6/incr/ + These patches are not incremental, meaning that for example the 2.6.12.3 patch does not apply on top of the 2.6.12.2 kernel source, but rather on top -of the base 2.6.12 kernel source. +of the base 2.6.12 kernel source . So, in order to apply the 2.6.12.3 patch to your existing 2.6.12.2 kernel source you have to first back out the 2.6.12.2 patch (so you are left with a base 2.6.12 kernel source) and then apply the new 2.6.12.3 patch. @@ -345,12 +353,12 @@ The -git kernels repository, hence the name). These patches are usually released daily and represent the current state of -Linus' tree. They are more experimental than -rc kernels since they are +Linus's tree. They are more experimental than -rc kernels since they are generated automatically without even a cursory glance to see if they are sane. -git patches are not incremental and apply either to a base 2.6.x kernel or -a base 2.6.x-rc kernel - you can see which from their name. +a base 2.6.x-rc kernel -- you can see which from their name. A patch named 2.6.12-git1 applies to the 2.6.12 kernel source and a patch named 2.6.13-rc3-git2 applies to the source of the 2.6.13-rc3 kernel. @@ -393,12 +401,12 @@ You should generally strive to get your patches into mainline via -mm to ensure maximum testing. This branch is in constant flux and contains many experimental features, a -lot of debugging patches not appropriate for mainline etc and is the most +lot of debugging patches not appropriate for mainline etc., and is the most experimental of the branches described in this document. These kernels are not appropriate for use on systems that are supposed to be stable and they are more risky to run than any of the other branches (make -sure you have up-to-date backups - that goes for any experimental kernel but +sure you have up-to-date backups -- that goes for any experimental kernel but even more so for -mm kernels). These kernels in addition to all the other experimental patches they contain diff --git a/Documentation/cpusets.txt b/Documentation/cpusets.txt index 9e49b1c..990998e 100644 --- a/Documentation/cpusets.txt +++ b/Documentation/cpusets.txt @@ -135,7 +135,7 @@ Cpusets extends these two mechanisms as follows: The implementation of cpusets requires a few, simple hooks into the rest of the kernel, none in performance critical paths: - - in main/init.c, to initialize the root cpuset at system boot. + - in init/main.c, to initialize the root cpuset at system boot. - in fork and exit, to attach and detach a task from its cpuset. - in sched_setaffinity, to mask the requested CPUs by what's allowed in that tasks cpuset. @@ -146,7 +146,7 @@ into the rest of the kernel, none in performance critical paths: and related changes in both sched.c and arch/ia64/kernel/domain.c - in the mbind and set_mempolicy system calls, to mask the requested Memory Nodes by what's allowed in that tasks cpuset. - - in page_alloc, to restrict memory to allowed nodes. + - in page_alloc.c, to restrict memory to allowed nodes. - in vmscan.c, to restrict page recovery to the current cpuset. In addition a new file system, of type "cpuset" may be mounted, diff --git a/Documentation/filesystems/ext3.txt b/Documentation/filesystems/ext3.txt index 22e4040..afb1335 100644 --- a/Documentation/filesystems/ext3.txt +++ b/Documentation/filesystems/ext3.txt @@ -2,11 +2,11 @@ Ext3 Filesystem =============== -ext3 was originally released in September 1999. Written by Stephen Tweedie -for 2.2 branch, and ported to 2.4 kernels by Peter Braam, Andreas Dilger, +Ext3 was originally released in September 1999. Written by Stephen Tweedie +for the 2.2 branch, and ported to 2.4 kernels by Peter Braam, Andreas Dilger, Andrew Morton, Alexander Viro, Ted Ts'o and Stephen Tweedie. -ext3 is ext2 filesystem enhanced with journalling capabilities. +Ext3 is the ext2 filesystem enhanced with journalling capabilities. Options ======= @@ -14,81 +14,81 @@ Options When mounting an ext3 filesystem, the following option are accepted: (*) == default -jounal=update Update the ext3 file system's journal to the - current format. +journal=update Update the ext3 file system's journal to the current + format. -journal=inum When a journal already exists, this option is - ignored. Otherwise, it specifies the number of - the inode which will represent the ext3 file - system's journal file. +journal=inum When a journal already exists, this option is ignored. + Otherwise, it specifies the number of the inode which + will represent the ext3 file system's journal file. journal_dev=devnum When the external journal device's major/minor numbers - have changed, this option allows to specify the new - journal location. The journal device is identified - through its new major/minor numbers encoded in devnum. + have changed, this option allows the user to specify + the new journal location. The journal device is + identified through its new major/minor numbers encoded + in devnum. noload Don't load the journal on mounting. -data=journal All data are committed into the journal prior - to being written into the main file system. +data=journal All data are committed into the journal prior to being + written into the main file system. data=ordered (*) All data are forced directly out to the main file - system prior to its metadata being committed to - the journal. + system prior to its metadata being committed to the + journal. -data=writeback Data ordering is not preserved, data may be - written into the main file system after its - metadata has been committed to the journal. +data=writeback Data ordering is not preserved, data may be written + into the main file system after its metadata has been + committed to the journal. commit=nrsec (*) Ext3 can be told to sync all its data and metadata every 'nrsec' seconds. The default value is 5 seconds. - This means that if you lose your power, you will lose, - as much, the latest 5 seconds of work (your filesystem - will not be damaged though, thanks to journaling). This - default value (or any low value) will hurt performance, - but it's good for data-safety. Setting it to 0 will - have the same effect than leaving the default 5 sec. + This means that if you lose your power, you will lose + as much as the latest 5 seconds of work (your + filesystem will not be damaged though, thanks to the + journaling). This default value (or any low value) + will hurt performance, but it's good for data-safety. + Setting it to 0 will have the same effect as leaving + it at the default (5 seconds). Setting it to very large values will improve performance. -barrier=1 This enables/disables barriers. barrier=0 disables it, - barrier=1 enables it. +barrier=1 This enables/disables barriers. barrier=0 disables + it, barrier=1 enables it. -orlov (*) This enables the new Orlov block allocator. It's enabled - by default. +orlov (*) This enables the new Orlov block allocator. It is + enabled by default. -oldalloc This disables the Orlov block allocator and enables the - old block allocator. Orlov should have better performance, - we'd like to get some feedback if it's the contrary for - you. +oldalloc This disables the Orlov block allocator and enables + the old block allocator. Orlov should have better + performance - we'd like to get some feedback if it's + the contrary for you. -user_xattr Enables Extended User Attributes. Additionally, you need - to have extended attribute support enabled in the kernel - configuration (CONFIG_EXT3_FS_XATTR). See the attr(5) - manual page and http://acl.bestbits.at to learn more - about extended attributes. +user_xattr Enables Extended User Attributes. Additionally, you + need to have extended attribute support enabled in the + kernel configuration (CONFIG_EXT3_FS_XATTR). See the + attr(5) manual page and http://acl.bestbits.at/ to + learn more about extended attributes. nouser_xattr Disables Extended User Attributes. -acl Enables POSIX Access Control Lists support. Additionally, - you need to have ACL support enabled in the kernel - configuration (CONFIG_EXT3_FS_POSIX_ACL). See the acl(5) - manual page and http://acl.bestbits.at for more - information. +acl Enables POSIX Access Control Lists support. + Additionally, you need to have ACL support enabled in + the kernel configuration (CONFIG_EXT3_FS_POSIX_ACL). + See the acl(5) manual page and http://acl.bestbits.at/ + for more information. -noacl This option disables POSIX Access Control List support. +noacl This option disables POSIX Access Control List + support. reservation noreservation -resize= - bsddf (*) Make 'df' act like BSD. minixdf Make 'df' act like Minix. check=none Don't do extra checking of bitmaps on mount. -nocheck +nocheck debug Extra debugging information is sent to syslog. @@ -97,7 +97,7 @@ errors=continue Keep going on a filesystem error. errors=panic Panic and halt the machine if an error occurs. grpid Give objects the same group ID as their creator. -bsdgroups +bsdgroups nogrpid (*) New objects have the group ID of their creator. sysvgroups @@ -108,81 +108,83 @@ resuid=n The user ID which may use the reserved blocks. sb=n Use alternate superblock at this location. -quota Quota options are currently silently ignored. -noquota (see fs/ext3/super.c, line 594) +quota +noquota grpquota usrquota Specification ============= -ext3 shares all disk implementation with ext2 filesystem, and add -transactions capabilities to ext2. Journaling is done by the -Journaling block device layer. +Ext3 shares all disk implementation with the ext2 filesystem, and adds +transactions capabilities to ext2. Journaling is done by the Journaling Block +Device layer. Journaling Block Device layer ----------------------------- -The Journaling Block Device layer (JBD) isn't ext3 specific. It was -design to add journaling capabilities on a block device. The ext3 -filesystem code will inform the JBD of modifications it is performing -(Call a transaction). the journal support the transactions start and -stop, and in case of crash, the journal can replayed the transactions -to put the partition on a consistent state fastly. +The Journaling Block Device layer (JBD) isn't ext3 specific. It was design to +add journaling capabilities on a block device. The ext3 filesystem code will +inform the JBD of modifications it is performing (called a transaction). The +journal supports the transactions start and stop, and in case of crash, the +journal can replayed the transactions to put the partition back in a +consistent state fast. -handles represent a single atomic update to a filesystem. JBD can -handle external journal on a block device. +Handles represent a single atomic update to a filesystem. JBD can handle an +external journal on a block device. Data Mode --------- -There's 3 different data modes: +There are 3 different data modes: * writeback mode -In data=writeback mode, ext3 does not journal data at all. This mode -provides a similar level of journaling as XFS, JFS, and ReiserFS in its -default mode - metadata journaling. A crash+recovery can cause -incorrect data to appear in files which were written shortly before the -crash. This mode will typically provide the best ext3 performance. +In data=writeback mode, ext3 does not journal data at all. This mode provides +a similar level of journaling as that of XFS, JFS, and ReiserFS in its default +mode - metadata journaling. A crash+recovery can cause incorrect data to +appear in files which were written shortly before the crash. This mode will +typically provide the best ext3 performance. * ordered mode -In data=ordered mode, ext3 only officially journals metadata, but it -logically groups metadata and data blocks into a single unit called a -transaction. When it's time to write the new metadata out to disk, the -associated data blocks are written first. In general, this mode -perform slightly slower than writeback but significantly faster than -journal mode. +In data=ordered mode, ext3 only officially journals metadata, but it logically +groups metadata and data blocks into a single unit called a transaction. When +it's time to write the new metadata out to disk, the associated data blocks +are written first. In general, this mode performs slightly slower than +writeback but significantly faster than journal mode. * journal mode -data=journal mode provides full data and metadata journaling. All new -data is written to the journal first, and then to its final location. -In the event of a crash, the journal can be replayed, bringing both -data and metadata into a consistent state. This mode is the slowest -except when data needs to be read from and written to disk at the same -time where it outperform all others mode. +data=journal mode provides full data and metadata journaling. All new data is +written to the journal first, and then to its final location. +In the event of a crash, the journal can be replayed, bringing both data and +metadata into a consistent state. This mode is the slowest except when data +needs to be read from and written to disk at the same time where it +outperforms all others modes. Compatibility ------------- Ext2 partitions can be easily convert to ext3, with `tune2fs -j <dev>`. -Ext3 is fully compatible with Ext2. Ext3 partitions can easily be -mounted as Ext2. +Ext3 is fully compatible with Ext2. Ext3 partitions can easily be mounted as +Ext2. + External Tools ============== -see manual pages to know more. +See manual pages to learn more. + +tune2fs: create a ext3 journal on a ext2 partition with the -j flag. +mke2fs: create a ext3 partition with the -j flag. +debugfs: ext2 and ext3 file system debugger. +ext2online: online (mounted) ext2 and ext3 filesystem resizer -tune2fs: create a ext3 journal on a ext2 partition with the -j flags -mke2fs: create a ext3 partition with the -j flags -debugfs: ext2 and ext3 file system debugger References ========== -kernel source: file:/usr/src/linux/fs/ext3 - file:/usr/src/linux/fs/jbd +kernel source: <file:fs/ext3/> + <file:fs/jbd/> -programs: http://e2fsprogs.sourceforge.net +programs: http://e2fsprogs.sourceforge.net/ + http://ext2resize.sourceforge.net -useful link: - http://www.zip.com.au/~akpm/linux/ext3/ext3-usage.html +useful links: http://www.zip.com.au/~akpm/linux/ext3/ext3-usage.html http://www-106.ibm.com/developerworks/linux/library/l-fs7/ http://www-106.ibm.com/developerworks/linux/library/l-fs8/ diff --git a/Documentation/hrtimers.txt b/Documentation/hrtimers.txt new file mode 100644 index 0000000..7620ff7 --- /dev/null +++ b/Documentation/hrtimers.txt @@ -0,0 +1,178 @@ + +hrtimers - subsystem for high-resolution kernel timers +---------------------------------------------------- + +This patch introduces a new subsystem for high-resolution kernel timers. + +One might ask the question: we already have a timer subsystem +(kernel/timers.c), why do we need two timer subsystems? After a lot of +back and forth trying to integrate high-resolution and high-precision +features into the existing timer framework, and after testing various +such high-resolution timer implementations in practice, we came to the +conclusion that the timer wheel code is fundamentally not suitable for +such an approach. We initially didnt believe this ('there must be a way +to solve this'), and spent a considerable effort trying to integrate +things into the timer wheel, but we failed. In hindsight, there are +several reasons why such integration is hard/impossible: + +- the forced handling of low-resolution and high-resolution timers in + the same way leads to a lot of compromises, macro magic and #ifdef + mess. The timers.c code is very "tightly coded" around jiffies and + 32-bitness assumptions, and has been honed and micro-optimized for a + relatively narrow use case (jiffies in a relatively narrow HZ range) + for many years - and thus even small extensions to it easily break + the wheel concept, leading to even worse compromises. The timer wheel + code is very good and tight code, there's zero problems with it in its + current usage - but it is simply not suitable to be extended for + high-res timers. + +- the unpredictable [O(N)] overhead of cascading leads to delays which + necessiate a more complex handling of high resolution timers, which + in turn decreases robustness. Such a design still led to rather large + timing inaccuracies. Cascading is a fundamental property of the timer + wheel concept, it cannot be 'designed out' without unevitably + degrading other portions of the timers.c code in an unacceptable way. + +- the implementation of the current posix-timer subsystem on top of + the timer wheel has already introduced a quite complex handling of + the required readjusting of absolute CLOCK_REALTIME timers at + settimeofday or NTP time - further underlying our experience by + example: that the timer wheel data structure is too rigid for high-res + timers. + +- the timer wheel code is most optimal for use cases which can be + identified as "timeouts". Such timeouts are usually set up to cover + error conditions in various I/O paths, such as networking and block + I/O. The vast majority of those timers never expire and are rarely + recascaded because the expected correct event arrives in time so they + can be removed from the timer wheel before any further processing of + them becomes necessary. Thus the users of these timeouts can accept + the granularity and precision tradeoffs of the timer wheel, and + largely expect the timer subsystem to have near-zero overhead. + Accurate timing for them is not a core purpose - in fact most of the + timeout values used are ad-hoc. For them it is at most a necessary + evil to guarantee the processing of actual timeout completions + (because most of the timeouts are deleted before completion), which + should thus be as cheap and unintrusive as possible. + +The primary users of precision timers are user-space applications that +utilize nanosleep, posix-timers and itimer interfaces. Also, in-kernel +users like drivers and subsystems which require precise timed events +(e.g. multimedia) can benefit from the availability of a seperate +high-resolution timer subsystem as well. + +While this subsystem does not offer high-resolution clock sources just +yet, the hrtimer subsystem can be easily extended with high-resolution +clock capabilities, and patches for that exist and are maturing quickly. +The increasing demand for realtime and multimedia applications along +with other potential users for precise timers gives another reason to +separate the "timeout" and "precise timer" subsystems. + +Another potential benefit is that such a seperation allows even more +special-purpose optimization of the existing timer wheel for the low +resolution and low precision use cases - once the precision-sensitive +APIs are separated from the timer wheel and are migrated over to +hrtimers. E.g. we could decrease the frequency of the timeout subsystem +from 250 Hz to 100 HZ (or even smaller). + +hrtimer subsystem implementation details +---------------------------------------- + +the basic design considerations were: + +- simplicity + +- data structure not bound to jiffies or any other granularity. All the + kernel logic works at 64-bit nanoseconds resolution - no compromises. + +- simplification of existing, timing related kernel code + +another basic requirement was the immediate enqueueing and ordering of +timers at activation time. After looking at several possible solutions +such as radix trees and hashes, we chose the red black tree as the basic +data structure. Rbtrees are available as a library in the kernel and are +used in various performance-critical areas of e.g. memory management and +file systems. The rbtree is solely used for time sorted ordering, while +a separate list is used to give the expiry code fast access to the +queued timers, without having to walk the rbtree. + +(This seperate list is also useful for later when we'll introduce +high-resolution clocks, where we need seperate pending and expired +queues while keeping the time-order intact.) + +Time-ordered enqueueing is not purely for the purposes of +high-resolution clocks though, it also simplifies the handling of +absolute timers based on a low-resolution CLOCK_REALTIME. The existing +implementation needed to keep an extra list of all armed absolute +CLOCK_REALTIME timers along with complex locking. In case of +settimeofday and NTP, all the timers (!) had to be dequeued, the +time-changing code had to fix them up one by one, and all of them had to +be enqueued again. The time-ordered enqueueing and the storage of the +expiry time in absolute time units removes all this complex and poorly +scaling code from the posix-timer implementation - the clock can simply +be set without having to touch the rbtree. This also makes the handling +of posix-timers simpler in general. + +The locking and per-CPU behavior of hrtimers was mostly taken from the +existing timer wheel code, as it is mature and well suited. Sharing code +was not really a win, due to the different data structures. Also, the +hrtimer functions now have clearer behavior and clearer names - such as +hrtimer_try_to_cancel() and hrtimer_cancel() [which are roughly +equivalent to del_timer() and del_timer_sync()] - so there's no direct +1:1 mapping between them on the algorithmical level, and thus no real +potential for code sharing either. + +Basic data types: every time value, absolute or relative, is in a +special nanosecond-resolution type: ktime_t. The kernel-internal +representation of ktime_t values and operations is implemented via +macros and inline functions, and can be switched between a "hybrid +union" type and a plain "scalar" 64bit nanoseconds representation (at +compile time). The hybrid union type optimizes time conversions on 32bit +CPUs. This build-time-selectable ktime_t storage format was implemented +to avoid the performance impact of 64-bit multiplications and divisions +on 32bit CPUs. Such operations are frequently necessary to convert +between the storage formats provided by kernel and userspace interfaces +and the internal time format. (See include/linux/ktime.h for further +details.) + +hrtimers - rounding of timer values +----------------------------------- + +the hrtimer code will round timer events to lower-resolution clocks +because it has to. Otherwise it will do no artificial rounding at all. + +one question is, what resolution value should be returned to the user by +the clock_getres() interface. This will return whatever real resolution +a given clock has - be it low-res, high-res, or artificially-low-res. + +hrtimers - testing and verification +---------------------------------- + +We used the high-resolution clock subsystem ontop of hrtimers to verify +the hrtimer implementation details in praxis, and we also ran the posix +timer tests in order to ensure specification compliance. We also ran +tests on low-resolution clocks. + +The hrtimer patch converts the following kernel functionality to use +hrtimers: + + - nanosleep + - itimers + - posix-timers + +The conversion of nanosleep and posix-timers enabled the unification of +nanosleep and clock_nanosleep. + +The code was successfully compiled for the following platforms: + + i386, x86_64, ARM, PPC, PPC64, IA64 + +The code was run-tested on the following platforms: + + i386(UP/SMP), x86_64(UP/SMP), ARM, PPC + +hrtimers were also integrated into the -rt tree, along with a +hrtimers-based high-resolution clock implementation, so the hrtimers +code got a healthy amount of testing and use in practice. + + Thomas Gleixner, Ingo Molnar diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index d802ce8..443230b 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -1033,9 +1033,9 @@ When kbuild executes the following steps are followed (roughly): Example: #arch/i386/Makefile - GCC_VERSION := $(call cc-version) cflags-y += $(shell \ - if [ $(GCC_VERSION) -ge 0300 ] ; then echo "-mregparm=3"; fi ;) + if [ $(call cc-version) -ge 0300 ] ; then \ + echo "-mregparm=3"; fi ;) In the above example -mregparm=3 is only used for gcc version greater than or equal to gcc 3.0. diff --git a/Documentation/kdump/gdbmacros.txt b/Documentation/kdump/gdbmacros.txt index bc1b9eb..dcf5580 100644 --- a/Documentation/kdump/gdbmacros.txt +++ b/Documentation/kdump/gdbmacros.txt @@ -177,3 +177,25 @@ document trapinfo 'trapinfo <pid>' will tell you by which trap & possibly addresthe kernel paniced. end + + +define dmesg + set $i = 0 + set $end_idx = (log_end - 1) & (log_buf_len - 1) + + while ($i < logged_chars) + set $idx = (log_end - 1 - logged_chars + $i) & (log_buf_len - 1) + + if ($idx + 100 <= $end_idx) || \ + ($end_idx <= $idx && $idx + 100 < log_buf_len) + printf "%.100s", &log_buf[$idx] + set $i = $i + 100 + else + printf "%c", log_buf[$idx] + set $i = $i + 1 + end + end +end +document dmesg + print the kernel ring buffer +end diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index 5f08f9c..212cf3c 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt @@ -4,10 +4,10 @@ Documentation for kdump - the kexec-based crash dumping solution DESIGN ====== -Kdump uses kexec to reboot to a second kernel whenever a dump needs to be taken. -This second kernel is booted with very little memory. The first kernel reserves -the section of memory that the second kernel uses. This ensures that on-going -DMA from the first kernel does not corrupt the second kernel. +Kdump uses kexec to reboot to a second kernel whenever a dump needs to be +taken. This second kernel is booted with very little memory. The first kernel +reserves the section of memory that the second kernel uses. This ensures that +on-going DMA from the first kernel does not corrupt the second kernel. All the necessary information about Core image is encoded in ELF format and stored in reserved area of memory before crash. Physical address of start of @@ -35,77 +35,82 @@ In the second kernel, "old memory" can be accessed in two ways. SETUP ===== -1) Download http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz - and apply http://lse.sourceforge.net/kdump/patches/kexec-tools-1.101-kdump.patch - and after that build the source. +1) Download the upstream kexec-tools userspace package from + http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz. -2) Download and build the appropriate (2.6.13-rc1 onwards) vanilla kernel. + Apply the latest consolidated kdump patch on top of kexec-tools-1.101 + from http://lse.sourceforge.net/kdump/. This arrangment has been made + till all the userspace patches supporting kdump are integrated with + upstream kexec-tools userspace. +2) Download and build the appropriate (2.6.13-rc1 onwards) vanilla kernels. Two kernels need to be built in order to get this feature working. + Following are the steps to properly configure the two kernels specific + to kexec and kdump features: - A) First kernel: + A) First kernel or regular kernel: + ---------------------------------- a) Enable "kexec system call" feature (in Processor type and features). - CONFIG_KEXEC=y - b) This kernel's physical load address should be the default value of - 0x100000 (0x100000, 1 MB) (in Processor type and features). - CONFIG_PHYSICAL_START=0x100000 - c) Enable "sysfs file system support" (in Pseudo filesystems). - CONFIG_SYSFS=y + CONFIG_KEXEC=y + b) Enable "sysfs file system support" (in Pseudo filesystems). + CONFIG_SYSFS=y + c) make d) Boot into first kernel with the command line parameter "crashkernel=Y@X". Use appropriate values for X and Y. Y denotes how much memory to reserve - for the second kernel, and X denotes at what physical address the reserved - memory section starts. For example: "crashkernel=64M@16M". - - B) Second kernel: - a) Enable "kernel crash dumps" feature (in Processor type and features). - CONFIG_CRASH_DUMP=y - b) Specify a suitable value for "Physical address where the kernel is - loaded" (in Processor type and features). Typically this value - should be same as X (See option d) above, e.g., 16 MB or 0x1000000. - CONFIG_PHYSICAL_START=0x1000000 - c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). - CONFIG_PROC_VMCORE=y - d) Disable SMP support and build a UP kernel (Until it is fixed). - CONFIG_SMP=n - e) Enable "Local APIC support on uniprocessors". - CONFIG_X86_UP_APIC=y - f) Enable "IO-APIC support on uniprocessors" - CONFIG_X86_UP_IOAPIC=y - - Note: i) Options a) and b) depend upon "Configure standard kernel features - (for small systems)" (under General setup). - ii) Option a) also depends on CONFIG_HIGHMEM (under Processor - type and features). - iii) Both option a) and b) are under "Processor type and features". - -3) Boot into the first kernel. You are now ready to try out kexec-based crash - dumps. - -4) Load the second kernel to be booted using: + for the second kernel, and X denotes at what physical address the + reserved memory section starts. For example: "crashkernel=64M@16M". + + + B) Second kernel or dump capture kernel: + --------------------------------------- + a) For i386 architecture enable Highmem support + CONFIG_HIGHMEM=y + b) Enable "kernel crash dumps" feature (under "Processor type and features") + CONFIG_CRASH_DUMP=y + c) Make sure a suitable value for "Physical address where the kernel is + loaded" (under "Processor type and features"). By default this value + is 0x1000000 (16MB) and it should be same as X (See option d above), + e.g., 16 MB or 0x1000000. + CONFIG_PHYSICAL_START=0x1000000 + d) Enable "/proc/vmcore support" (Optional, under "Pseudo filesystems"). + CONFIG_PROC_VMCORE=y + +3) After booting to regular kernel or first kernel, load the second kernel + using the following command: kexec -p <second-kernel> --args-linux --elf32-core-headers - --append="root=<root-dev> init 1 irqpoll" - - Note: i) <second-kernel> has to be a vmlinux image. bzImage will not work, - as of now. - ii) By default ELF headers are stored in ELF64 format. Option - --elf32-core-headers forces generation of ELF32 headers. gdb can - not open ELF64 headers on 32 bit systems. So creating ELF32 - headers can come handy for users who have got non-PAE systems and - hence have memory less than 4GB. - iii) Specify "irqpoll" as command line parameter. This reduces driver - initialization failures in second kernel due to shared interrupts. - iv) <root-dev> needs to be specified in a format corresponding to - the root device name in the output of mount command. - v) If you have built the drivers required to mount root file - system as modules in <second-kernel>, then, specify - --initrd=<initrd-for-second-kernel>. - -5) System reboots into the second kernel when a panic occurs. A module can be - written to force the panic or "ALT-SysRq-c" can be used initiate a crash - dump for testing purposes. - -6) Write out the dump file using + --append="root=<root-dev> init 1 irqpoll maxcpus=1" + + Notes: + ====== + i) <second-kernel> has to be a vmlinux image ie uncompressed elf image. + bzImage will not work, as of now. + ii) --args-linux has to be speicfied as if kexec it loading an elf image, + it needs to know that the arguments supplied are of linux type. + iii) By default ELF headers are stored in ELF64 format to support systems + with more than 4GB memory. Option --elf32-core-headers forces generation + of ELF32 headers. The reason for this option being, as of now gdb can + not open vmcore file with ELF64 headers on a 32 bit systems. So ELF32 + headers can be used if one has non-PAE systems and hence memory less + than 4GB. + iv) Specify "irqpoll" as command line parameter. This reduces driver + initialization failures in second kernel due to shared interrupts. + v) <root-dev> needs to be specified in a format corresponding to the root + device name in the output of mount command. + vi) If you have built the drivers required to mount root file system as + modules in <second-kernel>, then, specify + --initrd=<initrd-for-second-kernel>. + vii) Specify maxcpus=1 as, if during first kernel run, if panic happens on + non-boot cpus, second kernel doesn't seem to be boot up all the cpus. + The other option is to always built the second kernel without SMP + support ie CONFIG_SMP=n + +4) After successfully loading the second kernel as above, if a panic occurs + system reboots into the second kernel. A module can be written to force + the panic or "ALT-SysRq-c" can be used initiate a crash dump for testing + purposes. + +5) Once the second kernel has booted, write out the dump file using cp /proc/vmcore <dump-file> @@ -119,9 +124,9 @@ SETUP Entire memory: dd if=/dev/oldmem of=oldmem.001 + ANALYSIS ======== - Limited analysis can be done using gdb on the dump file copied out of /proc/vmcore. Use vmlinux built with -g and run @@ -132,15 +137,19 @@ work fine. Note: gdb cannot analyse core files generated in ELF64 format for i386. +Latest "crash" (crash-4.0-2.18) as available on Dave Anderson's site +http://people.redhat.com/~anderson/ works well with kdump format. + + TODO ==== - 1) Provide a kernel pages filtering mechanism so that core file size is not insane on systems having huge memory banks. -2) Modify "crash" tool to make it recognize this dump. +2) Relocatable kernel can help in maintaining multiple kernels for crashdump + and same kernel as the first kernel can be used to capture the dump. + CONTACT ======= - Vivek Goyal (vgoyal@in.ibm.com) Maneesh Soni (maneesh@in.ibm.com) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 0dc848b..fe11fcc 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -475,10 +475,11 @@ running once the system is up. See Documentation/block/as-iosched.txt and Documentation/block/deadline-iosched.txt for details. - elfcorehdr= [IA-32] + elfcorehdr= [IA-32, X86_64] Specifies physical address of start of kernel core - image elf header. - See Documentation/kdump.txt for details. + image elf header. Generally kexec loader will + pass this option to capture kernel. + See Documentation/kdump/kdump.txt for details. enforcing [SELINUX] Set initial enforcing status. Format: {"0" | "1"} @@ -832,7 +833,7 @@ running once the system is up. mem=nopentium [BUGS=IA-32] Disable usage of 4MB pages for kernel memory. - memmap=exactmap [KNL,IA-32] Enable setting of an exact + memmap=exactmap [KNL,IA-32,X86_64] Enable setting of an exact E820 memory map, as specified by the user. Such memmap=exactmap lines can be constructed based on BIOS output or other requirements. See the memmap=nn@ss @@ -855,6 +856,49 @@ running once the system is up. mga= [HW,DRM] + migration_cost= + [KNL,SMP] debug: override scheduler migration costs + Format: <level-1-usecs>,<level-2-usecs>,... + This debugging option can be used to override the + default scheduler migration cost matrix. The numbers + are indexed by 'CPU domain distance'. + E.g. migration_cost=1000,2000,3000 on an SMT NUMA + box will set up an intra-core migration cost of + 1 msec, an inter-core migration cost of 2 msecs, + and an inter-node migration cost of 3 msecs. + + WARNING: using the wrong values here can break + scheduler performance, so it's only for scheduler + development purposes, not production environments. + + migration_debug= + [KNL,SMP] migration cost auto-detect verbosity + Format=<0|1|2> + If a system's migration matrix reported at bootup + seems erroneous then this option can be used to + increase verbosity of the detection process. + We default to 0 (no extra messages), 1 will print + some more information, and 2 will be really + verbose (probably only useful if you also have a + serial console attached to the system). + + migration_factor= + [KNL,SMP] multiply/divide migration costs by a factor + Format=<percent> + This debug option can be used to proportionally + increase or decrease the auto-detected migration + costs for all entries of the migration matrix. + E.g. migration_factor=150 will increase migration + costs by 50%. (and thus the scheduler will be less + eager migrating cache-hot tasks) + migration_factor=80 will decrease migration costs + by 20%. (thus the scheduler will be more eager to + migrate tasks) + + WARNING: using the wrong values here can break + scheduler performance, so it's only for scheduler + development purposes, not production environments. + mousedev.tap_time= [MOUSE] Maximum time between finger touching and leaving touchpad surface for touch to be considered diff --git a/Documentation/laptop-mode.txt b/Documentation/laptop-mode.txt index dc4e810..f42e4c0 100644 --- a/Documentation/laptop-mode.txt +++ b/Documentation/laptop-mode.txt @@ -3,7 +3,7 @@ How to conserve battery power using laptop-mode Document Author: Bart Samwel (bart@samwel.tk) Date created: January 2, 2004 -Last modified: July 10, 2004 +Last modified: December 06, 2004 Introduction ------------ @@ -33,7 +33,7 @@ or anything. Simply install all the files included in this document, and laptop mode will automatically be started when you're on battery. For your convenience, a tarball containing an installer can be downloaded at: -http://www.xs4all.nl/~bsamwel/laptop_mode/tools +http://www.xs4all.nl/~bsamwel/laptop_mode/tools/ To configure laptop mode, you need to edit the configuration file, which is located in /etc/default/laptop-mode on Debian-based systems, or in @@ -912,7 +912,7 @@ void usage() exit(0); } -int main(int ac, char **av) +int main(int argc, char **argv) { int fd; char *disk = 0; diff --git a/Documentation/locks.txt b/Documentation/locks.txt index ce1be79..e3b402e 100644 --- a/Documentation/locks.txt +++ b/Documentation/locks.txt @@ -65,20 +65,3 @@ The default is to disallow mandatory locking. The intention is that mandatory locking only be enabled on a local filesystem as the specific need arises. -Until an updated version of mount(8) becomes available you may have to apply -this patch to the mount sources (based on the version distributed with Rick -Faith's util-linux-2.5 package): - -*** mount.c.orig Sat Jun 8 09:14:31 1996 ---- mount.c Sat Jun 8 09:13:02 1996 -*************** -*** 100,105 **** ---- 100,107 ---- - { "noauto", 0, MS_NOAUTO }, /* Can only be mounted explicitly */ - { "user", 0, MS_USER }, /* Allow ordinary user to mount */ - { "nouser", 1, MS_USER }, /* Forbid ordinary user to mount */ -+ { "mand", 0, MS_MANDLOCK }, /* Allow mandatory locks on this FS */ -+ { "nomand", 1, MS_MANDLOCK }, /* Forbid mandatory locks on this FS */ - /* add new options here */ - #ifdef MS_NOSUB - { "sub", 1, MS_NOSUB }, /* allow submounts */ diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt index 05960f8..2503404 100644 --- a/Documentation/oops-tracing.txt +++ b/Documentation/oops-tracing.txt @@ -41,11 +41,9 @@ the disk is not available then you have three options :- run a null modem to a second machine and capture the output there using your favourite communication program. Minicom works well. -(3) Patch the kernel with one of the crash dump patches. These save - data to a floppy disk or video rom or a swap partition. None of - these are standard kernel patches so you have to find and apply - them yourself. Search kernel archives for kmsgdump, lkcd and - oops+smram. +(3) Use Kdump (see Documentation/kdump/kdump.txt), + extract the kernel ring buffer from old memory with using dmesg + gdbmacro in Documentation/kdump/gdbmacros.txt. Full Information diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt index 2c81305..e409e5d 100644 --- a/Documentation/stable_kernel_rules.txt +++ b/Documentation/stable_kernel_rules.txt @@ -1,58 +1,56 @@ Everything you ever wanted to know about Linux 2.6 -stable releases. -Rules on what kind of patches are accepted, and what ones are not, into -the "-stable" tree: +Rules on what kind of patches are accepted, and which ones are not, into the +"-stable" tree: - It must be obviously correct and tested. - - It can not bigger than 100 lines, with context. + - It can not be bigger than 100 lines, with context. - It must fix only one thing. - It must fix a real bug that bothers people (not a, "This could be a - problem..." type thing.) + problem..." type thing). - It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real - security issue, or some "oh, that's not good" issue. In short, - something critical. - - No "theoretical race condition" issues, unless an explanation of how - the race can be exploited. + security issue, or some "oh, that's not good" issue. In short, something + critical. + - No "theoretical race condition" issues, unless an explanation of how the + race can be exploited is also provided. - It can not contain any "trivial" fixes in it (spelling changes, - whitespace cleanups, etc.) + whitespace cleanups, etc). - It must be accepted by the relevant subsystem maintainer. - - It must follow Documentation/SubmittingPatches rules. + - It must follow the Documentation/SubmittingPatches rules. Procedure for submitting patches to the -stable tree: - Send the patch, after verifying that it follows the above rules, to stable@kernel.org. - - The sender will receive an ack when the patch has been accepted into - the queue, or a nak if the patch is rejected. This response might - take a few days, according to the developer's schedules. - - If accepted, the patch will be added to the -stable queue, for review - by other developers. + - The sender will receive an ACK when the patch has been accepted into the + queue, or a NAK if the patch is rejected. This response might take a few + days, according to the developer's schedules. + - If accepted, the patch will be added to the -stable queue, for review by + other developers. - Security patches should not be sent to this alias, but instead to the - documented security@kernel.org. + documented security@kernel.org address. Review cycle: - - When the -stable maintainers decide for a review cycle, the patches - will be sent to the review committee, and the maintainer of the - affected area of the patch (unless the submitter is the maintainer of - the area) and CC: to the linux-kernel mailing list. - - The review committee has 48 hours in which to ack or nak the patch. + - When the -stable maintainers decide for a review cycle, the patches will be + sent to the review committee, and the maintainer of the affected area of + the patch (unless the submitter is the maintainer of the area) and CC: to + the linux-kernel mailing list. + - The review committee has 48 hours in which to ACK or NAK the patch. - If the patch is rejected by a member of the committee, or linux-kernel - members object to the patch, bringing up issues that the maintainers - and members did not realize, the patch will be dropped from the - queue. - - At the end of the review cycle, the acked patches will be added to - the latest -stable release, and a new -stable release will happen. - - Security patches will be accepted into the -stable tree directly from - the security kernel team, and not go through the normal review cycle. + members object to the patch, bringing up issues that the maintainers and + members did not realize, the patch will be dropped from the queue. + - At the end of the review cycle, the ACKed patches will be added to the + latest -stable release, and a new -stable release will happen. + - Security patches will be accepted into the -stable tree directly from the + security kernel team, and not go through the normal review cycle. Contact the kernel security team for more details on this procedure. Review committe: - - This will be made up of a number of kernel developers who have - volunteered for this task, and a few that haven't. - + - This is made up of a number of kernel developers who have volunteered for + this task, and a few that haven't. diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv index 74fb085..b72706c 100644 --- a/Documentation/video4linux/CARDLIST.bttv +++ b/Documentation/video4linux/CARDLIST.bttv @@ -142,3 +142,4 @@ 141 -> Asound Skyeye PCTV 142 -> Sabrent TV-FM (bttv version) 143 -> Hauppauge ImpactVCB (bt878) [0070:13eb] +144 -> MagicTV diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88 index 34b6e59..56e194f 100644 --- a/Documentation/video4linux/CARDLIST.cx88 +++ b/Documentation/video4linux/CARDLIST.cx88 @@ -19,7 +19,7 @@ 18 -> Hauppauge Nova-T DVB-T [0070:9002,0070:9001] 19 -> Conexant DVB-T reference design [14f1:0187] 20 -> Provideo PV259 [1540:2580] - 21 -> DViCO FusionHDTV DVB-T Plus [18ac:db10] + 21 -> DViCO FusionHDTV DVB-T Plus [18ac:db10,18ac:db11] 22 -> pcHDTV HD3000 HDTV [7063:3000] 23 -> digitalnow DNTV Live! DVB-T [17de:a8a6] 24 -> Hauppauge WinTV 28xxx (Roslyn) models [0070:2801] diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86_64/boot-options.txt index e566aff..72ab9b9 100644 --- a/Documentation/x86_64/boot-options.txt +++ b/Documentation/x86_64/boot-options.txt @@ -125,7 +125,7 @@ SMP cpumask=MASK only use cpus with bits set in mask additional_cpus=NUM Allow NUM more CPUs for hotplug - (defaults are specified by the BIOS or half the available CPUs) + (defaults are specified by the BIOS, see Documentation/x86_64/cpu-hotplug-spec) NUMA diff --git a/Documentation/x86_64/cpu-hotplug-spec b/Documentation/x86_64/cpu-hotplug-spec new file mode 100644 index 0000000..5c0fa34 --- /dev/null +++ b/Documentation/x86_64/cpu-hotplug-spec @@ -0,0 +1,21 @@ +Firmware support for CPU hotplug under Linux/x86-64 +--------------------------------------------------- + +Linux/x86-64 supports CPU hotplug now. For various reasons Linux wants to +know in advance boot time the maximum number of CPUs that could be plugged +into the system. ACPI 3.0 currently has no official way to supply +this information from the firmware to the operating system. + +In ACPI each CPU needs an LAPIC object in the MADT table (5.2.11.5 in the +ACPI 3.0 specification). ACPI already has the concept of disabled LAPIC +objects by setting the Enabled bit in the LAPIC object to zero. + +For CPU hotplug Linux/x86-64 expects now that any possible future hotpluggable +CPU is already available in the MADT. If the CPU is not available yet +it should have its LAPIC Enabled bit set to 0. Linux will use the number +of disabled LAPICs to compute the maximum number of future CPUs. + +In the worst case the user can overwrite this choice using a command line +option (additional_cpus=...), but it is recommended to supply the correct +number (or a reasonable approximation of it, with erring towards more not less) +in the MADT to avoid manual configuration. |