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

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

Merge branch 'linus' into sched/urgent 



Conflicts:
	kernel/sched_idletask.c

Merge reason: resolve the conflicts, pick up latest changes.

Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
parents b9f8fcd5 8bea8672

Documentation/ABI/testing/sysfs-devices-memory

+13 −1
Original line number Diff line number Diff line
@@ -60,6 +60,19 @@ Description: 
Users:		hotplug memory remove tools

		https://w3.opensource.ibm.com/projects/powerpc-utils/





What:		/sys/devices/system/memoryX/nodeY

Date:		October 2009

Contact:	Linux Memory Management list <linux-mm@kvack.org>

Description:

		When CONFIG_NUMA is enabled, a symbolic link that

		points to the corresponding NUMA node directory.



		For example, the following symbolic link is created for

		memory section 9 on node0:

		/sys/devices/system/memory/memory9/node0 -> ../../node/node0





What:		/sys/devices/system/node/nodeX/memoryY

Date:		September 2008

Contact:	Gary Hade <garyhade@us.ibm.com>
@@ -70,4 +83,3 @@ Description: 
		memory section directory.  For example, the following symbolic

		link is created for memory section 9 on node0.

		/sys/devices/system/node/node0/memory9 -> ../../memory/memory9

Documentation/ABI/testing/sysfs-devices-system-cpu

+14 −0
Original line number Diff line number Diff line
@@ -92,6 +92,20 @@ Description: Discover NUMA node a CPU belongs to 
		/sys/devices/system/cpu/cpu42/node2 -> ../../node/node2





What:		/sys/devices/system/cpu/cpu#/node

Date:		October 2009

Contact:	Linux memory management mailing list <linux-mm@kvack.org>

Description:	Discover NUMA node a CPU belongs to



		When CONFIG_NUMA is enabled, a symbolic link that points

		to the corresponding NUMA node directory.



		For example, the following symlink is created for cpu42

		in NUMA node 2:



		/sys/devices/system/cpu/cpu42/node2 -> ../../node/node2





What:		/sys/devices/system/cpu/cpu#/topology/core_id

		/sys/devices/system/cpu/cpu#/topology/core_siblings

		/sys/devices/system/cpu/cpu#/topology/core_siblings_list

Documentation/device-mapper/snapshot.txt

+55 −5
Original line number Diff line number Diff line
@@ -8,13 +8,19 @@ the block device which are also writable without interfering with the 
original content;

*) To create device "forks", i.e. multiple different versions of the

same data stream.

*) To merge a snapshot of a block device back into the snapshot's origin

device.



In the first two cases, dm copies only the chunks of data that get

changed and uses a separate copy-on-write (COW) block device for

storage.



In both cases, dm copies only the chunks of data that get changed and

uses a separate copy-on-write (COW) block device for storage.

For snapshot merge the contents of the COW storage are merged back into

the origin device.





There are two dm targets available: snapshot and snapshot-origin.

There are three dm targets available:

snapshot, snapshot-origin, and snapshot-merge.



*) snapshot-origin <origin>
@@ -40,8 +46,25 @@ The difference is that for transient snapshots less metadata must be 
saved on disk - they can be kept in memory by the kernel.





How this is used by LVM2

========================

* snapshot-merge <origin> <COW device> <persistent> <chunksize>



takes the same table arguments as the snapshot target except it only

works with persistent snapshots.  This target assumes the role of the

"snapshot-origin" target and must not be loaded if the "snapshot-origin"

is still present for <origin>.



Creates a merging snapshot that takes control of the changed chunks

stored in the <COW device> of an existing snapshot, through a handover

procedure, and merges these chunks back into the <origin>.  Once merging

has started (in the background) the <origin> may be opened and the merge

will continue while I/O is flowing to it.  Changes to the <origin> are

deferred until the merging snapshot's corresponding chunk(s) have been

merged.  Once merging has started the snapshot device, associated with

the "snapshot" target, will return -EIO when accessed.





How snapshot is used by LVM2

============================

When you create the first LVM2 snapshot of a volume, four dm devices are used:



1) a device containing the original mapping table of the source volume;
@@ -72,3 +95,30 @@ brw------- 1 root root 254, 12 29 ago 18:15 /dev/mapper/volumeGroup-snap-cow 
brw-------  1 root root 254, 13 29 ago 18:15 /dev/mapper/volumeGroup-snap

brw-------  1 root root 254, 10 29 ago 18:14 /dev/mapper/volumeGroup-base





How snapshot-merge is used by LVM2

==================================

A merging snapshot assumes the role of the "snapshot-origin" while

merging.  As such the "snapshot-origin" is replaced with

"snapshot-merge".  The "-real" device is not changed and the "-cow"

device is renamed to <origin name>-cow to aid LVM2's cleanup of the

merging snapshot after it completes.  The "snapshot" that hands over its

COW device to the "snapshot-merge" is deactivated (unless using lvchange

--refresh); but if it is left active it will simply return I/O errors.



A snapshot will merge into its origin with the following command:



lvconvert --merge volumeGroup/snap



we'll now have this situation:



# dmsetup table|grep volumeGroup



volumeGroup-base-real: 0 2097152 linear 8:19 384

volumeGroup-base-cow: 0 204800 linear 8:19 2097536

volumeGroup-base: 0 2097152 snapshot-merge 254:11 254:12 P 16



# ls -lL /dev/mapper/volumeGroup-*

brw-------  1 root root 254, 11 29 ago 18:15 /dev/mapper/volumeGroup-base-real

brw-------  1 root root 254, 12 29 ago 18:16 /dev/mapper/volumeGroup-base-cow

brw-------  1 root root 254, 10 29 ago 18:16 /dev/mapper/volumeGroup-base

Documentation/feature-removal-schedule.txt

+0 −16
Original line number Diff line number Diff line
@@ -291,22 +291,6 @@ Who: Michael Buesch <mb@bu3sch.de> 


---------------------------



What:	usedac i386 kernel parameter

When:	2.6.27

Why:	replaced by allowdac and no dac combination

Who:	Glauber Costa <gcosta@redhat.com>



---------------------------



What: print_fn_descriptor_symbol()

When: October 2009

Why:  The %pF vsprintf format provides the same functionality in a

      simpler way.  print_fn_descriptor_symbol() is deprecated but

      still present to give out-of-tree modules time to change.

Who:  Bjorn Helgaas <bjorn.helgaas@hp.com>



---------------------------



What:	/sys/o2cb symlink

When:	January 2010

Why:	/sys/fs/o2cb is the proper location for this information - /sys/o2cb

Documentation/filesystems/proc.txt

+9 −0
Original line number Diff line number Diff line
@@ -38,6 +38,7 @@ Table of Contents 
  3.3	/proc/<pid>/io - Display the IO accounting fields

  3.4	/proc/<pid>/coredump_filter - Core dump filtering settings

  3.5	/proc/<pid>/mountinfo - Information about mounts

  3.6	/proc/<pid>/comm  & /proc/<pid>/task/<tid>/comm





------------------------------------------------------------------------------
@@ -1409,3 +1410,11 @@ For more information on mount propagation see: 


  Documentation/filesystems/sharedsubtree.txt





3.6	/proc/<pid>/comm  & /proc/<pid>/task/<tid>/comm

--------------------------------------------------------

These files provide a method to access a tasks comm value. It also allows for

a task to set its own or one of its thread siblings comm value. The comm value

is limited in size compared to the cmdline value, so writing anything longer

then the kernel's TASK_COMM_LEN (currently 16 chars) will result in a truncated

comm value.