Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 154738
b: refs/heads/master
c: 5c5d4e8
h: refs/heads/master
v: v3
  • Loading branch information
Linus Torvalds committed Jul 1, 2009
1 parent 1e5b814 commit 10de9f1
Show file tree
Hide file tree
Showing 1,015 changed files with 31,357 additions and 11,349 deletions.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: c276aca46d26aa2347320096f8ecdf5016795c14
refs/heads/master: 5c5d4e8eafd0e54c2134c23296b1d7996c304fe1
4 changes: 2 additions & 2 deletions trunk/Documentation/block/data-integrity.txt
Original file line number Diff line number Diff line change
Expand Up @@ -50,7 +50,7 @@ encouraged them to allow separation of the data and integrity metadata
scatter-gather lists.

The controller will interleave the buffers on write and split them on
read. This means that the Linux can DMA the data buffers to and from
read. This means that Linux can DMA the data buffers to and from
host memory without changes to the page cache.

Also, the 16-bit CRC checksum mandated by both the SCSI and SATA specs
Expand All @@ -66,7 +66,7 @@ software RAID5).

The IP checksum is weaker than the CRC in terms of detecting bit
errors. However, the strength is really in the separation of the data
buffers and the integrity metadata. These two distinct buffers much
buffers and the integrity metadata. These two distinct buffers must
match up for an I/O to complete.

The separation of the data and integrity metadata buffers as well as
Expand Down
12 changes: 12 additions & 0 deletions trunk/Documentation/cgroups/cpusets.txt
Original file line number Diff line number Diff line change
Expand Up @@ -777,6 +777,18 @@ in cpuset directories:
# /bin/echo 1-4 > cpus -> set cpus list to cpus 1,2,3,4
# /bin/echo 1,2,3,4 > cpus -> set cpus list to cpus 1,2,3,4

To add a CPU to a cpuset, write the new list of CPUs including the
CPU to be added. To add 6 to the above cpuset:

# /bin/echo 1-4,6 > cpus -> set cpus list to cpus 1,2,3,4,6

Similarly to remove a CPU from a cpuset, write the new list of CPUs
without the CPU to be removed.

To remove all the CPUs:

# /bin/echo "" > cpus -> clear cpus list

2.3 Setting flags
-----------------

Expand Down
54 changes: 54 additions & 0 deletions trunk/Documentation/device-mapper/dm-log.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
Device-Mapper Logging
=====================
The device-mapper logging code is used by some of the device-mapper
RAID targets to track regions of the disk that are not consistent.
A region (or portion of the address space) of the disk may be
inconsistent because a RAID stripe is currently being operated on or
a machine died while the region was being altered. In the case of
mirrors, a region would be considered dirty/inconsistent while you
are writing to it because the writes need to be replicated for all
the legs of the mirror and may not reach the legs at the same time.
Once all writes are complete, the region is considered clean again.

There is a generic logging interface that the device-mapper RAID
implementations use to perform logging operations (see
dm_dirty_log_type in include/linux/dm-dirty-log.h). Various different
logging implementations are available and provide different
capabilities. The list includes:

Type Files
==== =====
disk drivers/md/dm-log.c
core drivers/md/dm-log.c
userspace drivers/md/dm-log-userspace* include/linux/dm-log-userspace.h

The "disk" log type
-------------------
This log implementation commits the log state to disk. This way, the
logging state survives reboots/crashes.

The "core" log type
-------------------
This log implementation keeps the log state in memory. The log state
will not survive a reboot or crash, but there may be a small boost in
performance. This method can also be used if no storage device is
available for storing log state.

The "userspace" log type
------------------------
This log type simply provides a way to export the log API to userspace,
so log implementations can be done there. This is done by forwarding most
logging requests to userspace, where a daemon receives and processes the
request.

The structure used for communication between kernel and userspace are
located in include/linux/dm-log-userspace.h. Due to the frequency,
diversity, and 2-way communication nature of the exchanges between
kernel and userspace, 'connector' is used as the interface for
communication.

There are currently two userspace log implementations that leverage this
framework - "clustered_disk" and "clustered_core". These implementations
provide a cluster-coherent log for shared-storage. Device-mapper mirroring
can be used in a shared-storage environment when the cluster log implementations
are employed.
39 changes: 39 additions & 0 deletions trunk/Documentation/device-mapper/dm-queue-length.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
dm-queue-length
===============

dm-queue-length is a path selector module for device-mapper targets,
which selects a path with the least number of in-flight I/Os.
The path selector name is 'queue-length'.

Table parameters for each path: [<repeat_count>]
<repeat_count>: The number of I/Os to dispatch using the selected
path before switching to the next path.
If not given, internal default is used. To check
the default value, see the activated table.

Status for each path: <status> <fail-count> <in-flight>
<status>: 'A' if the path is active, 'F' if the path is failed.
<fail-count>: The number of path failures.
<in-flight>: The number of in-flight I/Os on the path.


Algorithm
=========

dm-queue-length increments/decrements 'in-flight' when an I/O is
dispatched/completed respectively.
dm-queue-length selects a path with the minimum 'in-flight'.


Examples
========
In case that 2 paths (sda and sdb) are used with repeat_count == 128.

# echo "0 10 multipath 0 0 1 1 queue-length 0 2 1 8:0 128 8:16 128" \
dmsetup create test
#
# dmsetup table
test: 0 10 multipath 0 0 1 1 queue-length 0 2 1 8:0 128 8:16 128
#
# dmsetup status
test: 0 10 multipath 2 0 0 0 1 1 E 0 2 1 8:0 A 0 0 8:16 A 0 0
91 changes: 91 additions & 0 deletions trunk/Documentation/device-mapper/dm-service-time.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,91 @@
dm-service-time
===============

dm-service-time is a path selector module for device-mapper targets,
which selects a path with the shortest estimated service time for
the incoming I/O.

The service time for each path is estimated by dividing the total size
of in-flight I/Os on a path with the performance value of the path.
The performance value is a relative throughput value among all paths
in a path-group, and it can be specified as a table argument.

The path selector name is 'service-time'.

Table parameters for each path: [<repeat_count> [<relative_throughput>]]
<repeat_count>: The number of I/Os to dispatch using the selected
path before switching to the next path.
If not given, internal default is used. To check
the default value, see the activated table.
<relative_throughput>: The relative throughput value of the path
among all paths in the path-group.
The valid range is 0-100.
If not given, minimum value '1' is used.
If '0' is given, the path isn't selected while
other paths having a positive value are available.

Status for each path: <status> <fail-count> <in-flight-size> \
<relative_throughput>
<status>: 'A' if the path is active, 'F' if the path is failed.
<fail-count>: The number of path failures.
<in-flight-size>: The size of in-flight I/Os on the path.
<relative_throughput>: The relative throughput value of the path
among all paths in the path-group.


Algorithm
=========

dm-service-time adds the I/O size to 'in-flight-size' when the I/O is
dispatched and substracts when completed.
Basically, dm-service-time selects a path having minimum service time
which is calculated by:

('in-flight-size' + 'size-of-incoming-io') / 'relative_throughput'

However, some optimizations below are used to reduce the calculation
as much as possible.

1. If the paths have the same 'relative_throughput', skip
the division and just compare the 'in-flight-size'.

2. If the paths have the same 'in-flight-size', skip the division
and just compare the 'relative_throughput'.

3. If some paths have non-zero 'relative_throughput' and others
have zero 'relative_throughput', ignore those paths with zero
'relative_throughput'.

If such optimizations can't be applied, calculate service time, and
compare service time.
If calculated service time is equal, the path having maximum
'relative_throughput' may be better. So compare 'relative_throughput'
then.


Examples
========
In case that 2 paths (sda and sdb) are used with repeat_count == 128
and sda has an average throughput 1GB/s and sdb has 4GB/s,
'relative_throughput' value may be '1' for sda and '4' for sdb.

# echo "0 10 multipath 0 0 1 1 service-time 0 2 2 8:0 128 1 8:16 128 4" \
dmsetup create test
#
# dmsetup table
test: 0 10 multipath 0 0 1 1 service-time 0 2 2 8:0 128 1 8:16 128 4
#
# dmsetup status
test: 0 10 multipath 2 0 0 0 1 1 E 0 2 2 8:0 A 0 0 1 8:16 A 0 0 4


Or '2' for sda and '8' for sdb would be also true.

# echo "0 10 multipath 0 0 1 1 service-time 0 2 2 8:0 128 2 8:16 128 8" \
dmsetup create test
#
# dmsetup table
test: 0 10 multipath 0 0 1 1 service-time 0 2 2 8:0 128 2 8:16 128 8
#
# dmsetup status
test: 0 10 multipath 2 0 0 0 1 1 E 0 2 2 8:0 A 0 0 2 8:16 A 0 0 8
43 changes: 22 additions & 21 deletions trunk/Documentation/filesystems/Locking
Original file line number Diff line number Diff line change
Expand Up @@ -109,27 +109,28 @@ prototypes:

locking rules:
All may block.
BKL s_lock s_umount
alloc_inode: no no no
destroy_inode: no
dirty_inode: no (must not sleep)
write_inode: no
drop_inode: no !!!inode_lock!!!
delete_inode: no
put_super: yes yes no
write_super: no yes read
sync_fs: no no read
freeze_fs: ?
unfreeze_fs: ?
statfs: no no no
remount_fs: yes yes maybe (see below)
clear_inode: no
umount_begin: yes no no
show_options: no (vfsmount->sem)
quota_read: no no no (see below)
quota_write: no no no (see below)

->remount_fs() will have the s_umount lock if it's already mounted.
None have BKL
s_umount
alloc_inode:
destroy_inode:
dirty_inode: (must not sleep)
write_inode:
drop_inode: !!!inode_lock!!!
delete_inode:
put_super: write
write_super: read
sync_fs: read
freeze_fs: read
unfreeze_fs: read
statfs: no
remount_fs: maybe (see below)
clear_inode:
umount_begin: no
show_options: no (namespace_sem)
quota_read: no (see below)
quota_write: no (see below)

->remount_fs() will have the s_umount exclusive lock if it's already mounted.
When called from get_sb_single, it does NOT have the s_umount lock.
->quota_read() and ->quota_write() functions are both guaranteed to
be the only ones operating on the quota file by the quota code (via
Expand Down
25 changes: 16 additions & 9 deletions trunk/Documentation/gcov.txt
Original file line number Diff line number Diff line change
Expand Up @@ -188,13 +188,18 @@ Solution: Exclude affected source files from profiling by specifying
GCOV_PROFILE := n or GCOV_PROFILE_basename.o := n in the
corresponding Makefile.

Problem: Files copied from sysfs appear empty or incomplete.
Cause: Due to the way seq_file works, some tools such as cp or tar
may not correctly copy files from sysfs.
Solution: Use 'cat' to read .gcda files and 'cp -d' to copy links.
Alternatively use the mechanism shown in Appendix B.


Appendix A: gather_on_build.sh
==============================

Sample script to gather coverage meta files on the build machine
(see 6a):

#!/bin/bash

KSRC=$1
Expand Down Expand Up @@ -226,7 +231,7 @@ Appendix B: gather_on_test.sh
Sample script to gather coverage data files on the test machine
(see 6b):

#!/bin/bash
#!/bin/bash -e

DEST=$1
GCDA=/sys/kernel/debug/gcov
Expand All @@ -236,11 +241,13 @@ if [ -z "$DEST" ] ; then
exit 1
fi

find $GCDA -name '*.gcno' -o -name '*.gcda' | tar cfz $DEST -T -
TEMPDIR=$(mktemp -d)
echo Collecting data..
find $GCDA -type d -exec mkdir -p $TEMPDIR/\{\} \;
find $GCDA -name '*.gcda' -exec sh -c 'cat < $0 > '$TEMPDIR'/$0' {} \;
find $GCDA -name '*.gcno' -exec sh -c 'cp -d $0 '$TEMPDIR'/$0' {} \;
tar czf $DEST -C $TEMPDIR sys
rm -rf $TEMPDIR

if [ $? -eq 0 ] ; then
echo "$DEST successfully created, copy to build system and unpack with:"
echo " tar xfz $DEST"
else
echo "Could not create file $DEST"
fi
echo "$DEST successfully created, copy to build system and unpack with:"
echo " tar xfz $DEST"
20 changes: 10 additions & 10 deletions trunk/Documentation/kernel-parameters.txt
Original file line number Diff line number Diff line change
Expand Up @@ -229,14 +229,6 @@ and is between 256 and 4096 characters. It is defined in the file
to assume that this machine's pmtimer latches its value
and always returns good values.

acpi.power_nocheck= [HW,ACPI]
Format: 1/0 enable/disable the check of power state.
On some bogus BIOS the _PSC object/_STA object of
power resource can't return the correct device power
state. In such case it is unneccessary to check its
power state again in power transition.
1 : disable the power state check

acpi_sci= [HW,ACPI] ACPI System Control Interrupt trigger mode
Format: { level | edge | high | low }

Expand Down Expand Up @@ -1006,6 +998,7 @@ and is between 256 and 4096 characters. It is defined in the file
nomerge
forcesac
soft
pt [x86, IA64]

io7= [HW] IO7 for Marvel based alpha systems
See comment before marvel_specify_io7 in
Expand Down Expand Up @@ -1862,7 +1855,7 @@ and is between 256 and 4096 characters. It is defined in the file
IRQ routing is enabled.
noacpi [X86] Do not use ACPI for IRQ routing
or for PCI scanning.
nocrs [X86] Don't use _CRS for PCI resource
use_crs [X86] Use _CRS for PCI resource
allocation.
routeirq Do IRQ routing for all PCI devices.
This is normally done in pci_enable_device(),
Expand Down Expand Up @@ -1922,6 +1915,12 @@ and is between 256 and 4096 characters. It is defined in the file
Format: { 0 | 1 }
See arch/parisc/kernel/pdc_chassis.c

percpu_alloc= [X86] Select which percpu first chunk allocator to use.
Allowed values are one of "lpage", "embed" and "4k".
See comments in arch/x86/kernel/setup_percpu.c for
details on each allocator. This parameter is primarily
for debugging and performance comparison.

pf. [PARIDE]
See Documentation/blockdev/paride.txt.

Expand Down Expand Up @@ -2474,7 +2473,8 @@ and is between 256 and 4096 characters. It is defined in the file

tp720= [HW,PS2]

trace_buf_size=nn[KMG] [ftrace] will set tracing buffer size.
trace_buf_size=nn[KMG]
[FTRACE] will set tracing buffer size.

trix= [HW,OSS] MediaTrix AudioTrix Pro
Format:
Expand Down
Loading

0 comments on commit 10de9f1

Please sign in to comment.