---

yaml
---
r: 23669
b: refs/heads/master
c: d71eecf
h: refs/heads/master
i:
  23667: ea51f5d
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: a54123e27779049d27d21e6c8adfee73aa2c0734
+refs/heads/master: d71eecf3b8e893757cc3dec560c96a32ac090890

trunk/CREDITS

@@ -2007,13 +2007,14 @@ S: University of Stuttgart, Germany and
 S: Ecole Nationale Superieure des Telecommunications, Paris
 
 N: Jamie Lokier
-E: jamie@imbolc.ucc.ie
+E: jamie@shareable.org
+W: http://www.shareable.org/
 D: Reboot-through-BIOS for broken 486 motherboards
-D: Some parport fixes
-S: 11 Goodson Walk
-S: Marston
+D: Parport fixes, futex improvements
+D: First instruction of x86 sysenter path :)
+S: 51 Sunningwell Road
 S: Oxford
-S: OX3 0HX
+S: OX1 4SZ
 S: United Kingdom
 
 N: Mark Lord

trunk/Documentation/DocBook/deviceiobook.tmpl

@@ -270,25 +270,6 @@ CPU B:  spin_unlock_irqrestore(&dev_lock, flags)
       </para>
     </sect1>
 
-    <sect1>
-      <title>ISA legacy functions</title>
-      <para>
-	On older kernels (2.2 and earlier) the ISA bus could be read or
-	written with these functions and without ioremap being used. This is
-	no longer true in Linux 2.4. A set of equivalent functions exist for
-	easy legacy driver porting. The functions available are prefixed
-	with 'isa_' and are <function>isa_readb</function>,
-	<function>isa_writeb</function>, <function>isa_readw</function>, 
-	<function>isa_writew</function>, <function>isa_readl</function>,
-	<function>isa_writel</function>, <function>isa_memcpy_fromio</function>
-	and <function>isa_memcpy_toio</function>
-      </para>
-      <para>
-	These functions should not be used in new drivers, and will
-	eventually be going away.
-      </para>
-    </sect1>
-
   </chapter>
 
   <chapter>

trunk/Documentation/cpusets.txt

@@ -18,7 +18,8 @@ CONTENTS:
   1.4 What are exclusive cpusets ?
   1.5 What does notify_on_release do ?
   1.6 What is memory_pressure ?
-  1.7 How do I use cpusets ?
+  1.7 What is memory spread ?
+  1.8 How do I use cpusets ?
 2. Usage Examples and Syntax
   2.1 Basic Usage
   2.2 Adding/removing cpus
@@ -317,7 +318,78 @@ the tasks in the cpuset, in units of reclaims attempted per second,
 times 1000.
 
 
-1.7 How do I use cpusets ?
+1.7 What is memory spread ?
+---------------------------
+There are two boolean flag files per cpuset that control where the
+kernel allocates pages for the file system buffers and related in
+kernel data structures.  They are called 'memory_spread_page' and
+'memory_spread_slab'.
+
+If the per-cpuset boolean flag file 'memory_spread_page' is set, then
+the kernel will spread the file system buffers (page cache) evenly
+over all the nodes that the faulting task is allowed to use, instead
+of preferring to put those pages on the node where the task is running.
+
+If the per-cpuset boolean flag file 'memory_spread_slab' is set,
+then the kernel will spread some file system related slab caches,
+such as for inodes and dentries evenly over all the nodes that the
+faulting task is allowed to use, instead of preferring to put those
+pages on the node where the task is running.
+
+The setting of these flags does not affect anonymous data segment or
+stack segment pages of a task.
+
+By default, both kinds of memory spreading are off, and memory
+pages are allocated on the node local to where the task is running,
+except perhaps as modified by the tasks NUMA mempolicy or cpuset
+configuration, so long as sufficient free memory pages are available.
+
+When new cpusets are created, they inherit the memory spread settings
+of their parent.
+
+Setting memory spreading causes allocations for the affected page
+or slab caches to ignore the tasks NUMA mempolicy and be spread
+instead.    Tasks using mbind() or set_mempolicy() calls to set NUMA
+mempolicies will not notice any change in these calls as a result of
+their containing tasks memory spread settings.  If memory spreading
+is turned off, then the currently specified NUMA mempolicy once again
+applies to memory page allocations.
+
+Both 'memory_spread_page' and 'memory_spread_slab' are boolean flag
+files.  By default they contain "0", meaning that the feature is off
+for that cpuset.  If a "1" is written to that file, then that turns
+the named feature on.
+
+The implementation is simple.
+
+Setting the flag 'memory_spread_page' turns on a per-process flag
+PF_SPREAD_PAGE for each task that is in that cpuset or subsequently
+joins that cpuset.  The page allocation calls for the page cache
+is modified to perform an inline check for this PF_SPREAD_PAGE task
+flag, and if set, a call to a new routine cpuset_mem_spread_node()
+returns the node to prefer for the allocation.
+
+Similarly, setting 'memory_spread_cache' turns on the flag
+PF_SPREAD_SLAB, and appropriately marked slab caches will allocate
+pages from the node returned by cpuset_mem_spread_node().
+
+The cpuset_mem_spread_node() routine is also simple.  It uses the
+value of a per-task rotor cpuset_mem_spread_rotor to select the next
+node in the current tasks mems_allowed to prefer for the allocation.
+
+This memory placement policy is also known (in other contexts) as
+round-robin or interleave.
+
+This policy can provide substantial improvements for jobs that need
+to place thread local data on the corresponding node, but that need
+to access large file system data sets that need to be spread across
+the several nodes in the jobs cpuset in order to fit.  Without this
+policy, especially for jobs that might have one thread reading in the
+data set, the memory allocation across the nodes in the jobs cpuset
+can become very uneven.
+
+
+1.8 How do I use cpusets ?
 --------------------------
 
 In order to minimize the impact of cpusets on critical kernel

trunk/Documentation/feature-removal-schedule.txt

@@ -116,6 +116,17 @@ Who:	Harald Welte <laforge@netfilter.org>
 
 ---------------------------
 
+What:	remove EXPORT_SYMBOL(kernel_thread)
+When:	August 2006
+Files:	arch/*/kernel/*_ksyms.c
+Why:	kernel_thread is a low-level implementation detail.  Drivers should
+        use the <linux/kthread.h> API instead which shields them from
+	implementation details and provides a higherlevel interface that
+	prevents bugs and code duplication
+Who:	Christoph Hellwig <hch@lst.de>
+
+---------------------------
+
 What:	EXPORT_SYMBOL(lookup_hash)
 When:	January 2006
 Why:	Too low-level interface.  Use lookup_one_len or lookup_create instead.
@@ -165,6 +176,18 @@ Who:	Richard Knutsson <ricknu-0@student.ltu.se> and Greg Kroah-Hartman <gregkh@s
 
 ---------------------------
 
+What:	Usage of invalid timevals in setitimer
+When:	March 2007
+Why:	POSIX requires to validate timevals in the setitimer call. This
+	was never done by Linux. The invalid (e.g. negative timevals) were
+	silently converted to more or less random timeouts and intervals.
+	Until the removal a per boot limited number of warnings is printed
+	and the timevals are sanitized.
+
+Who:	Thomas Gleixner <tglx@linutronix.de>
+
+---------------------------
+
 What:	I2C interface of the it87 driver
 When:	January 2007
 Why:	The ISA interface is faster and should be always available. The I2C
@@ -174,6 +197,17 @@ Who:	Jean Delvare <khali@linux-fr.org>
 
 ---------------------------
 
+What:	remove EXPORT_SYMBOL(tasklist_lock)
+When:	August 2006
+Files:	kernel/fork.c
+Why:	tasklist_lock protects the kernel internal task list.  Modules have
+	no business looking at it, and all instances in drivers have been due
+	to use of too-lowlevel APIs.  Having this symbol exported prevents
+	moving to more scalable locking schemes for the task list.
+Who:	Christoph Hellwig <hch@lst.de>
+
+---------------------------
+
 What:	mount/umount uevents
 When:	February 2007
 Why:	These events are not correct, and do not properly let userspace know

trunk/Documentation/filesystems/v9fs.txt → trunk/Documentation/filesystems/9p.txt

@@ -1,5 +1,5 @@
-			V9FS: 9P2000 for Linux
-			======================
+	  	    v9fs: Plan 9 Resource Sharing for Linux
+		    =======================================
 
 ABOUT
 =====
@@ -9,18 +9,19 @@ v9fs is a Unix implementation of the Plan 9 9p remote filesystem protocol.
 This software was originally developed by Ron Minnich <rminnich@lanl.gov>
 and Maya Gokhale <maya@lanl.gov>.  Additional development by Greg Watson
 <gwatson@lanl.gov> and most recently Eric Van Hensbergen
-<ericvh@gmail.com> and Latchesar Ionkov <lucho@ionkov.net>.
+<ericvh@gmail.com>, Latchesar Ionkov <lucho@ionkov.net> and Russ Cox
+<rsc@swtch.com>.
 
 USAGE
 =====
 
 For remote file server:
 
-	mount -t 9P 10.10.1.2 /mnt/9
+	mount -t 9p 10.10.1.2 /mnt/9
 
 For Plan 9 From User Space applications (http://swtch.com/plan9)
 
-	mount -t 9P `namespace`/acme /mnt/9 -o proto=unix,name=$USER
+	mount -t 9p `namespace`/acme /mnt/9 -o proto=unix,uname=$USER
 
 OPTIONS
 =======
@@ -32,7 +33,7 @@ OPTIONS
  			fd   - used passed file descriptors for connection
                                 (see rfdno and wfdno)
 
-  name=name	user name to attempt mount as on the remote server.  The
+  uname=name	user name to attempt mount as on the remote server.  The
   		server may override or ignore this value.  Certain user
 		names may require authentication.
 
@@ -42,7 +43,7 @@ OPTIONS
   debug=n	specifies debug level.  The debug level is a bitmask.
   			0x01 = display verbose error messages
 			0x02 = developer debug (DEBUG_CURRENT)
-			0x04 = display 9P trace
+			0x04 = display 9p trace
 			0x08 = display VFS trace
 			0x10 = display Marshalling debug
 			0x20 = display RPC debug
@@ -53,11 +54,11 @@ OPTIONS
 
   wfdno=n	the file descriptor for writing with proto=fd
 
-  maxdata=n	the number of bytes to use for 9P packet payload (msize)
+  maxdata=n	the number of bytes to use for 9p packet payload (msize)
 
   port=n	port to connect to on the remote server
 
-  noextend	force legacy mode (no 9P2000.u semantics)
+  noextend	force legacy mode (no 9p2000.u semantics)
 
   uid		attempt to mount as a particular uid
 
@@ -72,7 +73,7 @@ OPTIONS
 RESOURCES
 =========
 
-The Linux version of the 9P server is now maintained under the npfs project
+The Linux version of the 9p server is now maintained under the npfs project
 on sourceforge (http://sourceforge.net/projects/npfs).
 
 There are user and developer mailing lists available through the v9fs project

trunk/Documentation/filesystems/udf.txt

@@ -26,6 +26,20 @@ The following mount options are supported:
 	nostrict	Unset strict conformance
 	iocharset=	Set the NLS character set
 
+The uid= and gid= options need a bit more explaining.  They will accept a
+decimal numeric value which will be used as the default ID for that mount.
+They will also accept the string "ignore" and "forget".  For files on the disk
+that are owned by nobody ( -1 ), they will instead look as if they are owned
+by the default ID.  The ignore option causes the default ID to override all
+IDs on the disk, not just -1.  The forget option causes all IDs to be written
+to disk as -1, so when the media is later remounted, they will appear to be
+owned by whatever default ID it is mounted with at that time.
+
+For typical desktop use of removable media, you should set the ID to that
+of the interactively logged on user, and also specify both the forget and
+ignore options.  This way the interactive user will always see the files
+on the disk as belonging to him.
+
 The remaining are for debugging and disaster recovery:
 
 	novrs		Skip volume sequence recognition