diff --git a/[refs] b/[refs] index 18eb83997176..100acb4b2fe5 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: 15a7c3bbe344d75e4891c7d30595899c12ccfaa1 +refs/heads/master: e30fdb1e026c2d05f216d2e5a25bfafdfd261ec2 diff --git a/trunk/CREDITS b/trunk/CREDITS index 66e82466dde8..5d75254bcb81 100644 --- a/trunk/CREDITS +++ b/trunk/CREDITS @@ -34,6 +34,7 @@ E: magrawal@nortelnetworks.com D: Basic Interphase 5575 driver with UBR and ABR support. S: 75 Donald St, Apt 42 S: Weymouth, MA 02188 +S: USA N: Dave Airlie E: airlied@linux.ie @@ -202,6 +203,7 @@ S: MS42 S: Hewlett-Packard S: 3404 E Harmony Rd S: Fort Collins, CO 80525 +S: USA N: Arindam Banerji E: axb@cse.nd.edu @@ -444,6 +446,7 @@ E: rbradetich@uswest.net D: Linux/PA-RISC hacker S: 1200 Goldenrod Dr. S: Nampa, Idaho 83686 +S: USA N: Derrick J. Brashear E: shadow@dementia.org @@ -633,6 +636,7 @@ E: scole@lanl.gov E: elenstev@mesatop.com D: Various build fixes and kernel documentation. S: Los Alamos, New Mexico +S: USA N: Hamish Coleman E: hamish@zot.apana.org.au @@ -951,6 +955,12 @@ S: Brevia 1043 S: S-114 79 Stockholm S: Sweden +N: Pekka Enberg +E: penberg@cs.helsinki.fi +W: http://www.cs.helsinki.fi/u/penberg/ +D: Various kernel hacks, fixes, and cleanups. +S: Finland + N: David Engebretsen E: engebret@us.ibm.com D: Linux port to 64-bit PowerPC architecture @@ -2003,6 +2013,7 @@ W: http://www.mathematik.uni-stuttgart.de/~floeff D: Busmaster driver for HP 10/100 Mbit Network Adapters S: University of Stuttgart, Germany and S: Ecole Nationale Superieure des Telecommunications, Paris +S: France N: Jamie Lokier E: jamie@shareable.org @@ -2172,6 +2183,7 @@ S: Hewlett Packard S: MS 42 S: 3404 E. Harmony Road S: Fort Collins, CO 80528 +S: USA N: Torben Mathiasen E: torben.mathiasen@compaq.com @@ -2228,6 +2240,12 @@ D: tc: HFSC scheduler S: Freiburg S: Germany +N: Paul E. McKenney +E: paulmck@us.ibm.com +W: http://www.rdrop.com/users/paulmck/ +D: RCU and variants +D: rcutorture module + N: Mike McLagan E: mike.mclagan@linux.org W: http://www.invlogic.com/~mmclagan @@ -2969,6 +2987,10 @@ S: 69 rue Dunois S: 75013 Paris S: France +N: Dipankar Sarma +E: dipankar@in.ibm.com +D: RCU + N: Hannu Savolainen E: hannu@opensound.com D: Maintainer of the sound drivers until 2.1.x days. @@ -3281,6 +3303,12 @@ S: 3 Ballow Crescent S: MacGregor A.C.T 2615 S: Australia +N: Josh Triplett +E: josh@freedesktop.org +P: 1024D/D0FE7AFB B24A 65C9 1D71 2AC2 DE87 CA26 189B 9946 D0FE 7AFB +D: rcutorture maintainer +D: lock annotations, finding and fixing lock bugs + N: Winfried Trümper E: winni@xpilot.org W: http://www.shop.de/~winni/ @@ -3652,7 +3680,7 @@ S: Portland, OR S: USA N: Michal Wronski -E: Michal.Wronski@motorola.com +E: michal.wronski@gmail.com D: POSIX message queues fs (with K. Benedyczak) S: Krakow S: Poland diff --git a/trunk/Documentation/DMA-mapping.txt b/trunk/Documentation/DMA-mapping.txt index 63392c9132b4..028614cdd062 100644 --- a/trunk/Documentation/DMA-mapping.txt +++ b/trunk/Documentation/DMA-mapping.txt @@ -107,7 +107,7 @@ The query is performed via a call to pci_set_dma_mask(): int pci_set_dma_mask(struct pci_dev *pdev, u64 device_mask); -The query for consistent allocations is performed via a a call to +The query for consistent allocations is performed via a call to pci_set_consistent_dma_mask(): int pci_set_consistent_dma_mask(struct pci_dev *pdev, u64 device_mask); @@ -117,7 +117,7 @@ device_mask is a bit mask describing which bits of a PCI address your device supports. It returns zero if your card can perform DMA properly on the machine given the address mask you provided. -If it returns non-zero, your device can not perform DMA properly on +If it returns non-zero, your device cannot perform DMA properly on this platform, and attempting to do so will result in undefined behavior. You must either use a different mask, or not use DMA. diff --git a/trunk/Documentation/DocBook/kernel-api.tmpl b/trunk/Documentation/DocBook/kernel-api.tmpl index 6d4b1ef5b6f1..2b5ac604948c 100644 --- a/trunk/Documentation/DocBook/kernel-api.tmpl +++ b/trunk/Documentation/DocBook/kernel-api.tmpl @@ -158,6 +158,7 @@ X!Ilib/string.c !Emm/filemap.c !Emm/memory.c !Emm/vmalloc.c +!Imm/page_alloc.c !Emm/mempool.c !Emm/page-writeback.c !Emm/truncate.c @@ -325,8 +326,13 @@ X!Ekernel/module.c !Ekernel/irq/manage.c + DMA Channels +!Ekernel/dma.c + + Resources Management !Ikernel/resource.c +!Ekernel/resource.c MTRR Handling diff --git a/trunk/Documentation/DocBook/libata.tmpl b/trunk/Documentation/DocBook/libata.tmpl index f9a7c064aec7..07a635590b36 100644 --- a/trunk/Documentation/DocBook/libata.tmpl +++ b/trunk/Documentation/DocBook/libata.tmpl @@ -1400,7 +1400,7 @@ and other resources, etc. When it's known that HBA is in ready state but ATA/ATAPI - device in in unknown state, reset only device. + device is in unknown state, reset only device. diff --git a/trunk/Documentation/DocBook/usb.tmpl b/trunk/Documentation/DocBook/usb.tmpl index 3608472d7b74..143e5ff7deb8 100644 --- a/trunk/Documentation/DocBook/usb.tmpl +++ b/trunk/Documentation/DocBook/usb.tmpl @@ -314,8 +314,7 @@ usbdevfs although it wasn't solving what devfs was. Every USB device will appear in usbfs, regardless of whether or - not it has a kernel driver; but only devices with kernel drivers - show up in devfs. + not it has a kernel driver. @@ -741,7 +740,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param) Synchronous I/O Support Synchronous requests involve the kernel blocking - until until the user mode request completes, either by + until the user mode request completes, either by finishing successfully or by reporting an error. In most cases this is the simplest way to use usbfs, although as noted above it does prevent performing I/O diff --git a/trunk/Documentation/DocBook/writing_usb_driver.tmpl b/trunk/Documentation/DocBook/writing_usb_driver.tmpl index 008a341234d0..07cd34c1940b 100644 --- a/trunk/Documentation/DocBook/writing_usb_driver.tmpl +++ b/trunk/Documentation/DocBook/writing_usb_driver.tmpl @@ -224,13 +224,8 @@ static int skel_probe(struct usb_interface *interface, Conversely, when the device is removed from the USB bus, the disconnect function is called with the device pointer. The driver needs to clean any private data that has been allocated at this time and to shut down any - pending urbs that are in the USB system. The driver also unregisters - itself from the devfs subsystem with the call: + pending urbs that are in the USB system. - -/* remove our devfs node */ -devfs_unregister(skel->devfs); - Now that the device is plugged into the system and the driver is bound to the device, any of the functions in the file_operations structure that diff --git a/trunk/Documentation/HOWTO b/trunk/Documentation/HOWTO index 1d6560413cc5..d6f3dd1a3464 100644 --- a/trunk/Documentation/HOWTO +++ b/trunk/Documentation/HOWTO @@ -375,6 +375,26 @@ of information is needed by the kernel developers to help track down the problem. +Managing bug reports +-------------------- + +One of the best ways to put into practice your hacking skills is by fixing +bugs reported by other people. Not only you will help to make the kernel +more stable, you'll learn to fix real world problems and you will improve +your skills, and other developers will be aware of your presence. Fixing +bugs is one of the best ways to earn merit amongst the developers, because +not many people like wasting time fixing other people's bugs. + +To work in the already reported bug reports, go to http://bugzilla.kernel.org. +If you want to be advised of the future bug reports, you can subscribe to the +bugme-new mailing list (only new bug reports are mailed here) or to the +bugme-janitor mailing list (every change in the bugzilla is mailed here) + + http://lists.osdl.org/mailman/listinfo/bugme-new + http://lists.osdl.org/mailman/listinfo/bugme-janitors + + + Mailing lists ------------- diff --git a/trunk/Documentation/IPMI.txt b/trunk/Documentation/IPMI.txt index 0256805b548f..0e3924ecd76b 100644 --- a/trunk/Documentation/IPMI.txt +++ b/trunk/Documentation/IPMI.txt @@ -326,9 +326,12 @@ for events, they will all receive all events that come in. For receiving commands, you have to individually register commands you want to receive. Call ipmi_register_for_cmd() and supply the netfn -and command name for each command you want to receive. Only one user -may be registered for each netfn/cmd, but different users may register -for different commands. +and command name for each command you want to receive. You also +specify a bitmask of the channels you want to receive the command from +(or use IPMI_CHAN_ALL for all channels if you don't care). Only one +user may be registered for each netfn/cmd/channel, but different users +may register for different commands, or the same command if the +channel bitmasks do not overlap. From userland, equivalent IOCTLs are provided to do these functions. @@ -361,6 +364,7 @@ You can change this at module load time (for a module) with: regspacings=,,... regsizes=,,... regshifts=,,... slave_addrs=,,... + force_kipmid=,,... Each of these except si_trydefaults is a list, the first item for the first interface, second item for the second interface, etc. @@ -406,7 +410,13 @@ The slave_addrs specifies the IPMI address of the local BMC. This is usually 0x20 and the driver defaults to that, but in case it's not, it can be specified when the driver starts up. -When compiled into the kernel, the addresses can be specified on the +The force_ipmid parameter forcefully enables (if set to 1) or disables +(if set to 0) the kernel IPMI daemon. Normally this is auto-detected +by the driver, but systems with broken interrupts might need an enable, +or users that don't want the daemon (don't need the performance, don't +want the CPU hit) can disable it. + +When compiled into the kernel, the parameters can be specified on the kernel command line as: ipmi_si.type=,... @@ -416,6 +426,7 @@ kernel command line as: ipmi_si.regsizes=,,... ipmi_si.regshifts=,,... ipmi_si.slave_addrs=,,... + ipmi_si.force_kipmid=,,... It works the same as the module parameters of the same names. @@ -457,12 +468,12 @@ BMCs specified on the smb_addr line will be detected. Setting smb_dbg_probe to 1 will enable debugging of the probing and detection process for BMCs on the SMBusses. -Discovering the IPMI compilant BMC on the SMBus can cause devices +Discovering the IPMI compliant BMC on the SMBus can cause devices on the I2C bus to fail. The SMBus driver writes a "Get Device ID" IPMI message as a block write to the I2C bus and waits for a response. This action can be detrimental to some I2C devices. It is highly recommended that the known I2c address be given to the SMBus driver in the smb_addr -parameter. The default adrress range will not be used when a smb_addr +parameter. The default address range will not be used when a smb_addr parameter is provided. When compiled into the kernel, the addresses can be specified on the diff --git a/trunk/Documentation/MSI-HOWTO.txt b/trunk/Documentation/MSI-HOWTO.txt index 3ec6c720b016..c70306abb7b2 100644 --- a/trunk/Documentation/MSI-HOWTO.txt +++ b/trunk/Documentation/MSI-HOWTO.txt @@ -267,7 +267,7 @@ y = The number of MSI capable devices populated in the system. vector reserved to avoid the case where some MSI-X capable drivers may attempt to claim all available vector resources. -z = The number of MSI-X capable devices pupulated in the system. +z = The number of MSI-X capable devices populated in the system. This policy ensures that maximum (x - y) is distributed evenly among MSI-X capable devices. diff --git a/trunk/Documentation/RCU/checklist.txt b/trunk/Documentation/RCU/checklist.txt index 1d50cf0c905e..f4dffadbcb00 100644 --- a/trunk/Documentation/RCU/checklist.txt +++ b/trunk/Documentation/RCU/checklist.txt @@ -221,3 +221,41 @@ over a rather long period of time, but improvements are always welcome! disable irq on a given acquisition of that lock will result in deadlock as soon as the RCU callback happens to interrupt that acquisition's critical section. + +13. SRCU (srcu_read_lock(), srcu_read_unlock(), and synchronize_srcu()) + may only be invoked from process context. Unlike other forms of + RCU, it -is- permissible to block in an SRCU read-side critical + section (demarked by srcu_read_lock() and srcu_read_unlock()), + hence the "SRCU": "sleepable RCU". Please note that if you + don't need to sleep in read-side critical sections, you should + be using RCU rather than SRCU, because RCU is almost always + faster and easier to use than is SRCU. + + Also unlike other forms of RCU, explicit initialization + and cleanup is required via init_srcu_struct() and + cleanup_srcu_struct(). These are passed a "struct srcu_struct" + that defines the scope of a given SRCU domain. Once initialized, + the srcu_struct is passed to srcu_read_lock(), srcu_read_unlock() + and synchronize_srcu(). A given synchronize_srcu() waits only + for SRCU read-side critical sections governed by srcu_read_lock() + and srcu_read_unlock() calls that have been passd the same + srcu_struct. This property is what makes sleeping read-side + critical sections tolerable -- a given subsystem delays only + its own updates, not those of other subsystems using SRCU. + Therefore, SRCU is less prone to OOM the system than RCU would + be if RCU's read-side critical sections were permitted to + sleep. + + The ability to sleep in read-side critical sections does not + come for free. First, corresponding srcu_read_lock() and + srcu_read_unlock() calls must be passed the same srcu_struct. + Second, grace-period-detection overhead is amortized only + over those updates sharing a given srcu_struct, rather than + being globally amortized as they are for other forms of RCU. + Therefore, SRCU should be used in preference to rw_semaphore + only in extremely read-intensive situations, or in situations + requiring SRCU's read-side deadlock immunity or low read-side + realtime latency. + + Note that, rcu_assign_pointer() and rcu_dereference() relate to + SRCU just as they do to other forms of RCU. diff --git a/trunk/Documentation/RCU/rcu.txt b/trunk/Documentation/RCU/rcu.txt index 02e27bf1d365..f84407cba816 100644 --- a/trunk/Documentation/RCU/rcu.txt +++ b/trunk/Documentation/RCU/rcu.txt @@ -45,7 +45,8 @@ o How can I see where RCU is currently used in the Linux kernel? Search for "rcu_read_lock", "rcu_read_unlock", "call_rcu", "rcu_read_lock_bh", "rcu_read_unlock_bh", "call_rcu_bh", - "synchronize_rcu", and "synchronize_net". + "srcu_read_lock", "srcu_read_unlock", "synchronize_rcu", + "synchronize_net", and "synchronize_srcu". o What guidelines should I follow when writing code that uses RCU? diff --git a/trunk/Documentation/RCU/torture.txt b/trunk/Documentation/RCU/torture.txt index a4948591607d..25a3c3f7d378 100644 --- a/trunk/Documentation/RCU/torture.txt +++ b/trunk/Documentation/RCU/torture.txt @@ -28,6 +28,15 @@ nreaders This is the number of RCU reading threads supported. To properly exercise RCU implementations with preemptible read-side critical sections. +nfakewriters This is the number of RCU fake writer threads to run. Fake + writer threads repeatedly use the synchronous "wait for + current readers" function of the interface selected by + torture_type, with a delay between calls to allow for various + different numbers of writers running in parallel. + nfakewriters defaults to 4, which provides enough parallelism + to trigger special cases caused by multiple writers, such as + the synchronize_srcu() early return optimization. + stat_interval The number of seconds between output of torture statistics (via printk()). Regardless of the interval, statistics are printed when the module is unloaded. @@ -44,9 +53,12 @@ test_no_idle_hz Whether or not to test the ability of RCU to operate in a kernel that disables the scheduling-clock interrupt to idle CPUs. Boolean parameter, "1" to test, "0" otherwise. -torture_type The type of RCU to test: "rcu" for the rcu_read_lock() - API, "rcu_bh" for the rcu_read_lock_bh() API, and "srcu" - for the "srcu_read_lock()" API. +torture_type The type of RCU to test: "rcu" for the rcu_read_lock() API, + "rcu_sync" for rcu_read_lock() with synchronous reclamation, + "rcu_bh" for the rcu_read_lock_bh() API, "rcu_bh_sync" for + rcu_read_lock_bh() with synchronous reclamation, "srcu" for + the "srcu_read_lock()" API, and "sched" for the use of + preempt_disable() together with synchronize_sched(). verbose Enable debug printk()s. Default is disabled. @@ -118,6 +130,21 @@ o "Free-Block Circulation": Shows the number of torture structures as it is only incremented if a torture structure's counter somehow gets incremented farther than it should. +Different implementations of RCU can provide implementation-specific +additional information. For example, SRCU provides the following: + + srcu-torture: rtc: f8cf46a8 ver: 355 tfle: 0 rta: 356 rtaf: 0 rtf: 346 rtmbe: 0 + srcu-torture: Reader Pipe: 559738 939 0 0 0 0 0 0 0 0 0 + srcu-torture: Reader Batch: 560434 243 0 0 0 0 0 0 0 0 + srcu-torture: Free-Block Circulation: 355 354 353 352 351 350 349 348 347 346 0 + srcu-torture: per-CPU(idx=1): 0(0,1) 1(0,1) 2(0,0) 3(0,1) + +The first four lines are similar to those for RCU. The last line shows +the per-CPU counter state. The numbers in parentheses are the values +of the "old" and "current" counters for the corresponding CPU. The +"idx" value maps the "old" and "current" values to the underlying array, +and is useful for debugging. + USAGE diff --git a/trunk/Documentation/RCU/whatisRCU.txt b/trunk/Documentation/RCU/whatisRCU.txt index 318df44259b3..e0d6d99b8f9b 100644 --- a/trunk/Documentation/RCU/whatisRCU.txt +++ b/trunk/Documentation/RCU/whatisRCU.txt @@ -582,7 +582,7 @@ The rcu_read_lock() and rcu_read_unlock() primitive read-acquire and release a global reader-writer lock. The synchronize_rcu() primitive write-acquires this same lock, then immediately releases it. This means that once synchronize_rcu() exits, all RCU read-side -critical sections that were in progress before synchonize_rcu() was +critical sections that were in progress before synchronize_rcu() was called are guaranteed to have completed -- there is no way that synchronize_rcu() would have been able to write-acquire the lock otherwise. @@ -750,7 +750,7 @@ Or, for those who prefer a side-by-side listing: Either way, the differences are quite small. Read-side locking moves to rcu_read_lock() and rcu_read_unlock, update-side locking moves from -from a reader-writer lock to a simple spinlock, and a synchronize_rcu() +a reader-writer lock to a simple spinlock, and a synchronize_rcu() precedes the kfree(). However, there is one potential catch: the read-side and update-side @@ -778,6 +778,8 @@ Markers for RCU read-side critical sections: rcu_read_unlock rcu_read_lock_bh rcu_read_unlock_bh + srcu_read_lock + srcu_read_unlock RCU pointer/list traversal: @@ -804,6 +806,7 @@ RCU grace period: synchronize_net synchronize_sched synchronize_rcu + synchronize_srcu call_rcu call_rcu_bh diff --git a/trunk/Documentation/SubmitChecklist b/trunk/Documentation/SubmitChecklist index a6cb6ffd2933..7ac61f60037a 100644 --- a/trunk/Documentation/SubmitChecklist +++ b/trunk/Documentation/SubmitChecklist @@ -64,3 +64,5 @@ kernel patches. 19: All new userspace interfaces are documented in Documentation/ABI/. See Documentation/ABI/README for more information. + +20: Check that it all passes `make headers_check'. diff --git a/trunk/Documentation/accounting/getdelays.c b/trunk/Documentation/accounting/getdelays.c index 795ca3911cc5..b11792abd6b6 100644 --- a/trunk/Documentation/accounting/getdelays.c +++ b/trunk/Documentation/accounting/getdelays.c @@ -285,7 +285,7 @@ int main(int argc, char *argv[]) if (maskset) { rc = send_cmd(nl_sd, id, mypid, TASKSTATS_CMD_GET, TASKSTATS_CMD_ATTR_REGISTER_CPUMASK, - &cpumask, sizeof(cpumask)); + &cpumask, strlen(cpumask) + 1); PRINTF("Sent register cpumask, retval %d\n", rc); if (rc < 0) { printf("error sending register cpumask\n"); @@ -315,7 +315,8 @@ int main(int argc, char *argv[]) } if (msg.n.nlmsg_type == NLMSG_ERROR || !NLMSG_OK((&msg.n), rep_len)) { - printf("fatal reply error, errno %d\n", errno); + struct nlmsgerr *err = NLMSG_DATA(&msg); + printf("fatal reply error, errno %d\n", err->error); goto done; } @@ -383,7 +384,7 @@ int main(int argc, char *argv[]) if (maskset) { rc = send_cmd(nl_sd, id, mypid, TASKSTATS_CMD_GET, TASKSTATS_CMD_ATTR_DEREGISTER_CPUMASK, - &cpumask, sizeof(cpumask)); + &cpumask, strlen(cpumask) + 1); printf("Sent deregister mask, retval %d\n", rc); if (rc < 0) err(rc, "error sending deregister cpumask\n"); diff --git a/trunk/Documentation/accounting/taskstats-struct.txt b/trunk/Documentation/accounting/taskstats-struct.txt new file mode 100644 index 000000000000..661c797eaf79 --- /dev/null +++ b/trunk/Documentation/accounting/taskstats-struct.txt @@ -0,0 +1,161 @@ +The struct taskstats +-------------------- + +This document contains an explanation of the struct taskstats fields. + +There are three different groups of fields in the struct taskstats: + +1) Common and basic accounting fields + If CONFIG_TASKSTATS is set, the taskstats inteface is enabled and + the common fields and basic accounting fields are collected for + delivery at do_exit() of a task. +2) Delay accounting fields + These fields are placed between + /* Delay accounting fields start */ + and + /* Delay accounting fields end */ + Their values are collected if CONFIG_TASK_DELAY_ACCT is set. +3) Extended accounting fields + These fields are placed between + /* Extended accounting fields start */ + and + /* Extended accounting fields end */ + Their values are collected if CONFIG_TASK_XACCT is set. + +Future extension should add fields to the end of the taskstats struct, and +should not change the relative position of each field within the struct. + + +struct taskstats { + +1) Common and basic accounting fields: + /* The version number of this struct. This field is always set to + * TAKSTATS_VERSION, which is defined in . + * Each time the struct is changed, the value should be incremented. + */ + __u16 version; + + /* The exit code of a task. */ + __u32 ac_exitcode; /* Exit status */ + + /* The accounting flags of a task as defined in + * Defined values are AFORK, ASU, ACOMPAT, ACORE, and AXSIG. + */ + __u8 ac_flag; /* Record flags */ + + /* The value of task_nice() of a task. */ + __u8 ac_nice; /* task_nice */ + + /* The name of the command that started this task. */ + char ac_comm[TS_COMM_LEN]; /* Command name */ + + /* The scheduling discipline as set in task->policy field. */ + __u8 ac_sched; /* Scheduling discipline */ + + __u8 ac_pad[3]; + __u32 ac_uid; /* User ID */ + __u32 ac_gid; /* Group ID */ + __u32 ac_pid; /* Process ID */ + __u32 ac_ppid; /* Parent process ID */ + + /* The time when a task begins, in [secs] since 1970. */ + __u32 ac_btime; /* Begin time [sec since 1970] */ + + /* The elapsed time of a task, in [usec]. */ + __u64 ac_etime; /* Elapsed time [usec] */ + + /* The user CPU time of a task, in [usec]. */ + __u64 ac_utime; /* User CPU time [usec] */ + + /* The system CPU time of a task, in [usec]. */ + __u64 ac_stime; /* System CPU time [usec] */ + + /* The minor page fault count of a task, as set in task->min_flt. */ + __u64 ac_minflt; /* Minor Page Fault Count */ + + /* The major page fault count of a task, as set in task->maj_flt. */ + __u64 ac_majflt; /* Major Page Fault Count */ + + +2) Delay accounting fields: + /* Delay accounting fields start + * + * All values, until the comment "Delay accounting fields end" are + * available only if delay accounting is enabled, even though the last + * few fields are not delays + * + * xxx_count is the number of delay values recorded + * xxx_delay_total is the corresponding cumulative delay in nanoseconds + * + * xxx_delay_total wraps around to zero on overflow + * xxx_count incremented regardless of overflow + */ + + /* Delay waiting for cpu, while runnable + * count, delay_total NOT updated atomically + */ + __u64 cpu_count; + __u64 cpu_delay_total; + + /* Following four fields atomically updated using task->delays->lock */ + + /* Delay waiting for synchronous block I/O to complete + * does not account for delays in I/O submission + */ + __u64 blkio_count; + __u64 blkio_delay_total; + + /* Delay waiting for page fault I/O (swap in only) */ + __u64 swapin_count; + __u64 swapin_delay_total; + + /* cpu "wall-clock" running time + * On some architectures, value will adjust for cpu time stolen + * from the kernel in involuntary waits due to virtualization. + * Value is cumulative, in nanoseconds, without a corresponding count + * and wraps around to zero silently on overflow + */ + __u64 cpu_run_real_total; + + /* cpu "virtual" running time + * Uses time intervals seen by the kernel i.e. no adjustment + * for kernel's involuntary waits due to virtualization. + * Value is cumulative, in nanoseconds, without a corresponding count + * and wraps around to zero silently on overflow + */ + __u64 cpu_run_virtual_total; + /* Delay accounting fields end */ + /* version 1 ends here */ + + +3) Extended accounting fields + /* Extended accounting fields start */ + + /* Accumulated RSS usage in duration of a task, in MBytes-usecs. + * The current rss usage is added to this counter every time + * a tick is charged to a task's system time. So, at the end we + * will have memory usage multiplied by system time. Thus an + * average usage per system time unit can be calculated. + */ + __u64 coremem; /* accumulated RSS usage in MB-usec */ + + /* Accumulated virtual memory usage in duration of a task. + * Same as acct_rss_mem1 above except that we keep track of VM usage. + */ + __u64 virtmem; /* accumulated VM usage in MB-usec */ + + /* High watermark of RSS usage in duration of a task, in KBytes. */ + __u64 hiwater_rss; /* High-watermark of RSS usage */ + + /* High watermark of VM usage in duration of a task, in KBytes. */ + __u64 hiwater_vm; /* High-water virtual memory usage */ + + /* The following four fields are I/O statistics of a task. */ + __u64 read_char; /* bytes read */ + __u64 write_char; /* bytes written */ + __u64 read_syscalls; /* read syscalls */ + __u64 write_syscalls; /* write syscalls */ + + /* Extended accounting fields end */ + +} diff --git a/trunk/Documentation/aoe/todo.txt b/trunk/Documentation/aoe/todo.txt index 7fee1e1165bc..c09dfad4aed8 100644 --- a/trunk/Documentation/aoe/todo.txt +++ b/trunk/Documentation/aoe/todo.txt @@ -7,7 +7,7 @@ not been observed, but it would be nice to eliminate any potential for deadlock under memory pressure. Because ATA over Ethernet is not fragmented by the kernel's IP code, -the destructore member of the struct sk_buff is available to the aoe +the destructor member of the struct sk_buff is available to the aoe driver. By using a mempool for allocating all but the first few sk_buffs, and by registering a destructor, we should be able to efficiently allocate sk_buffs without introducing any potential for diff --git a/trunk/Documentation/arm/SA1100/serial_UART b/trunk/Documentation/arm/SA1100/serial_UART index aea2e91ca0ef..a63966f1d083 100644 --- a/trunk/Documentation/arm/SA1100/serial_UART +++ b/trunk/Documentation/arm/SA1100/serial_UART @@ -24,8 +24,8 @@ The SA1100 serial port had its major/minor numbers officially assigned: > 7 = /dev/cusa2 Callout device for ttySA2 > -If you're not using devfs, you must create those inodes in /dev -on the root filesystem used by your SA1100-based device: +You must create those inodes in /dev on the root filesystem used +by your SA1100-based device: mknod ttySA0 c 204 5 mknod ttySA1 c 204 6 diff --git a/trunk/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt b/trunk/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt index 000e3d7a78b2..26422f0f9080 100644 --- a/trunk/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt +++ b/trunk/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt @@ -38,7 +38,7 @@ MTD --- The NAND and NOR support has been merged from the linux-mtd project. - Any prolbems, see http://www.linux-mtd.infradead.org/ for more + Any problems, see http://www.linux-mtd.infradead.org/ for more information or up-to-date versions of linux-mtd. diff --git a/trunk/Documentation/arm/Samsung-S3C24XX/GPIO.txt b/trunk/Documentation/arm/Samsung-S3C24XX/GPIO.txt index 0822764ec270..8caea8c237ee 100644 --- a/trunk/Documentation/arm/Samsung-S3C24XX/GPIO.txt +++ b/trunk/Documentation/arm/Samsung-S3C24XX/GPIO.txt @@ -24,7 +24,7 @@ Headers header include/asm-arm/arch-s3c2410/hardware.h which can be included by #include - A useful ammount of documentation can be found in the hardware + A useful amount of documentation can be found in the hardware header on how the GPIO functions (and others) work. Whilst a number of these functions do make some checks on what diff --git a/trunk/Documentation/arm/Samsung-S3C24XX/Overview.txt b/trunk/Documentation/arm/Samsung-S3C24XX/Overview.txt index 3e46d2a31158..dda7ecdde87b 100644 --- a/trunk/Documentation/arm/Samsung-S3C24XX/Overview.txt +++ b/trunk/Documentation/arm/Samsung-S3C24XX/Overview.txt @@ -80,7 +80,7 @@ Machines Adding New Machines ------------------- - The archicture has been designed to support as many machines as can + The architecture has been designed to support as many machines as can be configured for it in one kernel build, and any future additions should keep this in mind before altering items outside of their own machine files. diff --git a/trunk/Documentation/arm/Samsung-S3C24XX/S3C2412.txt b/trunk/Documentation/arm/Samsung-S3C24XX/S3C2412.txt index cb82a7fc7901..295d971a15ed 100644 --- a/trunk/Documentation/arm/Samsung-S3C24XX/S3C2412.txt +++ b/trunk/Documentation/arm/Samsung-S3C24XX/S3C2412.txt @@ -80,7 +80,7 @@ RTC Watchdog -------- - The watchdog harware is the same as the S3C2410, and is supported by + The watchdog hardware is the same as the S3C2410, and is supported by the s3c2410_wdt driver. diff --git a/trunk/Documentation/block/as-iosched.txt b/trunk/Documentation/block/as-iosched.txt index 6f47332c883d..e2a66f8143c5 100644 --- a/trunk/Documentation/block/as-iosched.txt +++ b/trunk/Documentation/block/as-iosched.txt @@ -99,8 +99,8 @@ contrast, many write requests may be dispatched to the disk controller at a time during a write batch. It is this characteristic that can make the anticipatory scheduler perform anomalously with controllers supporting TCQ, or with hardware striped RAID devices. Setting the antic_expire -queue paramter (see below) to zero disables this behavior, and the anticipatory -scheduler behaves essentially like the deadline scheduler. +queue parameter (see below) to zero disables this behavior, and the +anticipatory scheduler behaves essentially like the deadline scheduler. When read anticipation is enabled (antic_expire is not zero), reads are dispatched to the disk controller one at a time. diff --git a/trunk/Documentation/block/barrier.txt b/trunk/Documentation/block/barrier.txt index 03971518b222..a272c3db8094 100644 --- a/trunk/Documentation/block/barrier.txt +++ b/trunk/Documentation/block/barrier.txt @@ -25,7 +25,7 @@ of the following three ways. i. For devices which have queue depth greater than 1 (TCQ devices) and support ordered tags, block layer can just issue the barrier as an ordered request and the lower level driver, controller and drive -itself are responsible for making sure that the ordering contraint is +itself are responsible for making sure that the ordering constraint is met. Most modern SCSI controllers/drives should support this. NOTE: SCSI ordered tag isn't currently used due to limitation in the @@ -42,7 +42,7 @@ iii. Devices which have queue depth of 1. This is a degenerate case of ii. Just keeping issue order suffices. Ancient SCSI controllers/drives and IDE drives are in this category. -2. Forced flushing to physcial medium +2. Forced flushing to physical medium Again, if you're not gonna do synchronization with disk drives (dang, it sounds even more appealing now!), the reason you use I/O barriers @@ -56,7 +56,7 @@ There are four cases, i. No write-back cache. Keeping requests ordered is enough. ii. Write-back cache but no flush operation. There's no way to -gurantee physical-medium commit order. This kind of devices can't to +guarantee physical-medium commit order. This kind of devices can't to I/O barriers. iii. Write-back cache and flush operation but no FUA (forced unit diff --git a/trunk/Documentation/block/biodoc.txt b/trunk/Documentation/block/biodoc.txt index f989a9e839b4..34bf8f60d8f8 100644 --- a/trunk/Documentation/block/biodoc.txt +++ b/trunk/Documentation/block/biodoc.txt @@ -135,7 +135,7 @@ Some new queue property settings: Sets two variables that limit the size of the request. - The request queue's max_sectors, which is a soft size in - in units of 512 byte sectors, and could be dynamically varied + units of 512 byte sectors, and could be dynamically varied by the core kernel. - The request queue's max_hw_sectors, which is a hard limit @@ -783,7 +783,7 @@ all the outstanding requests. There's a third helper to do that: blk_queue_invalidate_tags(request_queue_t *q) - Clear the internal block tag queue and readd all the pending requests + Clear the internal block tag queue and re-add all the pending requests to the request queue. The driver will receive them again on the next request_fn run, just like it did the first time it encountered them. @@ -890,7 +890,7 @@ Aside: Kvec i/o: - Ben LaHaise's aio code uses a slighly different structure instead + Ben LaHaise's aio code uses a slightly different structure instead of kiobufs, called a kvec_cb. This contains an array of tuples (very much like the networking code), together with a callback function and data pointer. This is embedded into a brw_cb structure when passed @@ -988,7 +988,7 @@ elevator_exit_fn Allocate and free any elevator specific storage for a queue. 4.2 Request flows seen by I/O schedulers -All requests seens by I/O schedulers strictly follow one of the following three +All requests seen by I/O schedulers strictly follow one of the following three flows. set_req_fn -> @@ -1203,6 +1203,6 @@ temporarily map a bio into the virtual address space. and Linus' comments - Jan 2001) 9.2 Discussions about kiobuf and bh design on lkml between sct, linus, alan et al - Feb-March 2001 (many of the initial thoughts that led to bio were -brought up in this discusion thread) +brought up in this discussion thread) 9.3 Discussions on mempool on lkml - Dec 2001. diff --git a/trunk/Documentation/block/deadline-iosched.txt b/trunk/Documentation/block/deadline-iosched.txt index c918b3a6022d..be08ffd1e9b8 100644 --- a/trunk/Documentation/block/deadline-iosched.txt +++ b/trunk/Documentation/block/deadline-iosched.txt @@ -23,11 +23,11 @@ you can do so by typing: read_expire (in ms) ----------- -The goal of the deadline io scheduler is to attempt to guarentee a start +The goal of the deadline io scheduler is to attempt to guarantee a start service time for a request. As we focus mainly on read latencies, this is tunable. When a read request first enters the io scheduler, it is assigned a deadline that is the current time + the read_expire value in units of -miliseconds. +milliseconds. write_expire (in ms) diff --git a/trunk/Documentation/cciss.txt b/trunk/Documentation/cciss.txt index 9c629ffa0e58..f74affe5c829 100644 --- a/trunk/Documentation/cciss.txt +++ b/trunk/Documentation/cciss.txt @@ -80,7 +80,7 @@ the /proc filesystem entry which the "block" side of the driver creates as the SCSI core may not yet be initialized (because the driver is a block driver) and attempting to register it with the SCSI core in such a case would cause a hang. This is best done via an initialization script -(typically in /etc/init.d, but could vary depending on distibution). +(typically in /etc/init.d, but could vary depending on distribution). For example: for x in /proc/driver/cciss/cciss[0-9]* @@ -152,7 +152,7 @@ side during the SCSI error recovery process, the cciss driver only implements the first two of these actions, aborting the command, and resetting the device. Additionally, most tape drives will not oblige in aborting commands, and sometimes it appears they will not even -obey a reset coommand, though in most circumstances they will. In +obey a reset command, though in most circumstances they will. In the case that the command cannot be aborted and the device cannot be reset, the device will be set offline. diff --git a/trunk/Documentation/computone.txt b/trunk/Documentation/computone.txt index b1cf59b84d97..5e2a0c76bfa0 100644 --- a/trunk/Documentation/computone.txt +++ b/trunk/Documentation/computone.txt @@ -199,30 +199,6 @@ boxes this will leave gaps in the sequence of device names. ip2mkdev uses Linux tty naming conventions: ttyF0 - ttyF255 for normal devices, and cuf0 - cuf255 for callout devices. -If you are using devfs, existing devices are automatically created within -the devfs name space. Normal devices will be tts/F0 - tts/F255 and callout -devices will be cua/F0 - cua/F255. With devfs installed, ip2mkdev will -create symbolic links in /dev from the old conventional names to the newer -devfs names as follows: - - /dev/ip2ipl[n] -> /dev/ip2/ipl[n] n = 0 - 3 - /dev/ip2stat[n] -> /dev/ip2/stat[n] n = 0 - 3 - /dev/ttyF[n] -> /dev/tts/F[n] n = 0 - 255 - /dev/cuf[n] -> /dev/cua/F[n] n = 0 - 255 - -Only devices for existing ports and boards will be created. - -IMPORTANT NOTE: The naming convention used for devfs by this driver -was changed from 1.2.12 to 1.2.13. The old naming convention was to -use ttf/%d for the tty device and cuf/%d for the cua device. That -has been changed to conform to an agreed-upon standard of placing -all the tty devices under tts. The device names are now tts/F%d for -the tty device and cua/F%d for the cua devices. If you were using -the older devfs names, you must update for the newer convention. - -You do not need to run ip2mkdev if you are using devfs and only want to -use the devfs native device names. - 4. USING THE DRIVERS @@ -256,57 +232,15 @@ cut out and run as "ip2mkdev" to create the necessary device files. To use the ip2mkdev script, you must have procfs enabled and the proc file system mounted on /proc. -You do not need to run ip2mkdev if you are using devfs and only want to -use the devfs native device names. - - -6. DEVFS - -DEVFS is the DEVice File System available as an add on package for the -2.2.x kernels and available as a configuration option in 2.3.46 and higher. -Devfs allows for the automatic creation and management of device names -under control of the device drivers themselves. The Devfs namespace is -hierarchical and reduces the clutter present in the normal flat /dev -namespace. Devfs names and conventional device names may be intermixed. -A userspace daemon, devfsd, exists to allow for automatic creation and -management of symbolic links from the devfs name space to the conventional -names. More details on devfs can be found on the DEVFS home site at - or in the file kernel -documentation files, .../linux/Documentation/filesystems/devfs/README. - -If you are using devfs, existing devices are automatically created within -the devfs name space. Normal devices will be tts/F0 - tts/F255 and callout -devices will be cua/F0 - cua/F255. With devfs installed, ip2mkdev will -create symbolic links in /dev from the old conventional names to the newer -devfs names as follows: - - /dev/ip2ipl[n] -> /dev/ip2/ipl[n] n = 0 - 3 - /dev/ip2stat[n] -> /dev/ip2/stat[n] n = 0 - 3 - /dev/ttyF[n] -> /dev/tts/F[n] n = 0 - 255 - /dev/cuf[n] -> /dev/cua/F[n] n = 0 - 255 - -Only devices for existing ports and boards will be created. - -IMPORTANT NOTE: The naming convention used for devfs by this driver -was changed from 1.2.12 to 1.2.13. The old naming convention was to -use ttf/%d for the tty device and cuf/%d for the cua device. That -has been changed to conform to an agreed-upon standard of placing -all the tty devices under tts. The device names are now tts/F%d for -the tty device and cua/F%d for the cua devices. If you were using -the older devfs names, you must update for the newer convention. - -You do not need to run ip2mkdev if you are using devfs and only want to -use the devfs native device names. - -7. NOTES +6. NOTES This is a release version of the driver, but it is impossible to test it in all configurations of Linux. If there is any anomalous behaviour that does not match the standard serial port's behaviour please let us know. -8. ip2mkdev shell script +7. ip2mkdev shell script Previously, this script was simply attached here. It is now attached as a shar archive to make it easier to extract the script from the documentation. diff --git a/trunk/Documentation/cpu-freq/cpufreq-stats.txt b/trunk/Documentation/cpu-freq/cpufreq-stats.txt index 6a82948ff4bd..53d62c1e1c94 100644 --- a/trunk/Documentation/cpu-freq/cpufreq-stats.txt +++ b/trunk/Documentation/cpu-freq/cpufreq-stats.txt @@ -1,5 +1,5 @@ - CPU frequency and voltage scaling statictics in the Linux(TM) kernel + CPU frequency and voltage scaling statistics in the Linux(TM) kernel L i n u x c p u f r e q - s t a t s d r i v e r @@ -18,8 +18,8 @@ Contents 1. Introduction cpufreq-stats is a driver that provices CPU frequency statistics for each CPU. -This statistics is provided in /sysfs as a bunch of read_only interfaces. This -interface (when configured) will appear in a seperate directory under cpufreq +These statistics are provided in /sysfs as a bunch of read_only interfaces. This +interface (when configured) will appear in a separate directory under cpufreq in /sysfs (/devices/system/cpu/cpuX/cpufreq/stats/) for each CPU. Various statistics will form read_only files under this directory. @@ -53,7 +53,7 @@ drwxr-xr-x 3 root root 0 May 14 15:58 .. This gives the amount of time spent in each of the frequencies supported by this CPU. The cat output will have "