Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit f14eff1c authored by Ingo Molnar's avatar Ingo Molnar
Browse files

Merge commit 'v2.6.31-rc8' into sched/core 



Merge reason: bump from rc5 to rc8, but also pick up TP_perf_assign()
              API, a patch will be queued that depends on it.

Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
parents 84e9dabf 326ba501

Documentation/ABI/testing/sysfs-block

+23 −14
Original line number Diff line number Diff line
@@ -94,28 +94,37 @@ What: /sys/block/<disk>/queue/physical_block_size 
Date:		May 2009

Contact:	Martin K. Petersen <martin.petersen@oracle.com>

Description:

		This is the smallest unit the storage device can write

		without resorting to read-modify-write operation.  It is

		usually the same as the logical block size but may be

		bigger.  One example is SATA drives with 4KB sectors

		that expose a 512-byte logical block size to the

		operating system.

		This is the smallest unit a physical storage device can

		write atomically.  It is usually the same as the logical

		block size but may be bigger.  One example is SATA

		drives with 4KB sectors that expose a 512-byte logical

		block size to the operating system.  For stacked block

		devices the physical_block_size variable contains the

		maximum physical_block_size of the component devices.



What:		/sys/block/<disk>/queue/minimum_io_size

Date:		April 2009

Contact:	Martin K. Petersen <martin.petersen@oracle.com>

Description:

		Storage devices may report a preferred minimum I/O size,

		which is the smallest request the device can perform

		without incurring a read-modify-write penalty.  For disk

		drives this is often the physical block size.  For RAID

		arrays it is often the stripe chunk size.

		Storage devices may report a granularity or preferred

		minimum I/O size which is the smallest request the

		device can perform without incurring a performance

		penalty.  For disk drives this is often the physical

		block size.  For RAID arrays it is often the stripe

		chunk size.  A properly aligned multiple of

		minimum_io_size is the preferred request size for

		workloads where a high number of I/O operations is

		desired.



What:		/sys/block/<disk>/queue/optimal_io_size

Date:		April 2009

Contact:	Martin K. Petersen <martin.petersen@oracle.com>

Description:

		Storage devices may report an optimal I/O size, which is

		the device's preferred unit of receiving I/O.  This is

		rarely reported for disk drives.  For RAID devices it is

		usually the stripe width or the internal block size.
 
		the device's preferred unit for sustained I/O.  This is

		rarely reported for disk drives.  For RAID arrays it is

		usually the stripe width or the internal track size.  A

		properly aligned multiple of optimal_io_size is the

		preferred request size for workloads where sustained

		throughput is desired.  If no optimal I/O size is

		reported this file contains 0.

Documentation/DocBook/kernel-hacking.tmpl

+2 −2
Original line number Diff line number Diff line
@@ -449,8 +449,8 @@ printk(KERN_INFO "i = %u\n", i); 
   </para>



   <programlisting>

__u32 ipaddress;

printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));

__be32 ipaddress;

printk(KERN_INFO "my ip: %pI4\n", &amp;ipaddress);

   </programlisting>



   <para>

Documentation/arm/memory.txt

+2 −0
Original line number Diff line number Diff line
@@ -21,6 +21,8 @@ ffff8000 ffffffff copy_user_page / clear_user_page use. 
				For SA11xx and Xscale, this is used to

				setup a minicache mapping.



ffff4000	ffffffff	cache aliasing on ARMv6 and later CPUs.



ffff1000	ffff7fff	Reserved.

				Platforms must not use this address range.

Documentation/filesystems/9p.txt

+3 −0
Original line number Diff line number Diff line
@@ -123,6 +123,9 @@ available from the same CVS repository. 
There are user and developer mailing lists available through the v9fs project

on sourceforge (http://sourceforge.net/projects/v9fs).



A stand-alone version of the module (which should build for any 2.6 kernel)

is available via (http://github.com/ericvh/9p-sac/tree/master)



News and other information is maintained on SWiK (http://swik.net/v9fs).



Bug reports may be issued through the kernel.org bugzilla

Documentation/filesystems/afs.txt

+12 −14
Original line number Diff line number Diff line
@@ -23,15 +23,13 @@ it does support include: 


 (*) Security (currently only AFS kaserver and KerberosIV tickets).



 (*) File reading.

 (*) File reading and writing.



 (*) Automounting.



It does not yet support the following AFS features:



 (*) Write support.

 (*) Local caching (via fscache).



 (*) Local caching.

It does not yet support the following AFS features:



 (*) pioctl() system call.
@@ -56,7 +54,7 @@ They permit the debugging messages to be turned on dynamically by manipulating 
the masks in the following files:



	/sys/module/af_rxrpc/parameters/debug

	/sys/module/afs/parameters/debug

	/sys/module/kafs/parameters/debug





=====
@@ -66,9 +64,9 @@ USAGE 
When inserting the driver modules the root cell must be specified along with a

list of volume location server IP addresses:



	insmod af_rxrpc.o

	insmod rxkad.o

	insmod kafs.o rootcell=cambridge.redhat.com:172.16.18.73:172.16.18.91

	modprobe af_rxrpc

	modprobe rxkad

	modprobe kafs rootcell=cambridge.redhat.com:172.16.18.73:172.16.18.91



The first module is the AF_RXRPC network protocol driver.  This provides the

RxRPC remote operation protocol and may also be accessed from userspace.  See:
@@ -81,7 +79,7 @@ is the actual filesystem driver for the AFS filesystem. 
Once the module has been loaded, more modules can be added by the following

procedure:



	echo add grand.central.org 18.7.14.88:128.2.191.224 >/proc/fs/afs/cells

	echo add grand.central.org 18.9.48.14:128.2.203.61:130.237.48.87 >/proc/fs/afs/cells



Where the parameters to the "add" command are the name of a cell and a list of

volume location servers within that cell, with the latter separated by colons.
@@ -101,7 +99,7 @@ The name of the volume can be suffixes with ".backup" or ".readonly" to 
specify connection to only volumes of those types.



The name of the cell is optional, and if not given during a mount, then the

named volume will be looked up in the cell specified during insmod.

named volume will be looked up in the cell specified during modprobe.



Additional cells can be added through /proc (see later section).
@@ -163,14 +161,14 @@ THE CELL DATABASE 


The filesystem maintains an internal database of all the cells it knows and the

IP addresses of the volume location servers for those cells.  The cell to which

the system belongs is added to the database when insmod is performed by the

the system belongs is added to the database when modprobe is performed by the

"rootcell=" argument or, if compiled in, using a "kafs.rootcell=" argument on

the kernel command line.



Further cells can be added by commands similar to the following:



	echo add CELLNAME VLADDR[:VLADDR][:VLADDR]... >/proc/fs/afs/cells

	echo add grand.central.org 18.7.14.88:128.2.191.224 >/proc/fs/afs/cells

	echo add grand.central.org 18.9.48.14:128.2.203.61:130.237.48.87 >/proc/fs/afs/cells



No other cell database operations are available at this time.
@@ -233,7 +231,7 @@ insmod /tmp/kafs.o rootcell=cambridge.redhat.com:172.16.18.91 
mount -t afs \%root.afs. /afs

mount -t afs \%cambridge.redhat.com:root.cell. /afs/cambridge.redhat.com/



echo add grand.central.org 18.7.14.88:128.2.191.224 > /proc/fs/afs/cells

echo add grand.central.org 18.9.48.14:128.2.203.61:130.237.48.87 > /proc/fs/afs/cells

mount -t afs "#grand.central.org:root.cell." /afs/grand.central.org/

mount -t afs "#grand.central.org:root.archive." /afs/grand.central.org/archive

mount -t afs "#grand.central.org:root.contrib." /afs/grand.central.org/contrib