Commit d30cc16c authored by Tony Lindgren's avatar Tony Lindgren
Browse files

Merge branch 'fixes-modulesplit' into fixes

parents 41eb2d81 a1bcc1dc
...@@ -71,3 +71,10 @@ Description: Value of 1 indicates the controller can honor the reset_devices ...@@ -71,3 +71,10 @@ Description: Value of 1 indicates the controller can honor the reset_devices
a dump device, as kdump requires resetting the device in order a dump device, as kdump requires resetting the device in order
to work reliably. to work reliably.
Where: /sys/bus/pci/devices/<dev>/ccissX/transport_mode
Date: July 2011
Kernel Version: 3.0
Contact: iss_storagedev@hp.com
Description: Value of "simple" indicates that the controller has been placed
in "simple mode". Value of "performant" indicates that the
controller has been placed in "performant mode".
...@@ -166,8 +166,8 @@ if (condition) ...@@ -166,8 +166,8 @@ if (condition)
else else
do_that(); do_that();
This does not apply if one branch of a conditional statement is a single This does not apply if only one branch of a conditional statement is a single
statement. Use braces in both branches. statement; in the latter case use braces in both branches:
if (condition) { if (condition) {
do_this(); do_this();
......
...@@ -50,6 +50,13 @@ specify the GFP_ flags (see kmalloc) for the allocation (the ...@@ -50,6 +50,13 @@ specify the GFP_ flags (see kmalloc) for the allocation (the
implementation may choose to ignore flags that affect the location of implementation may choose to ignore flags that affect the location of
the returned memory, like GFP_DMA). the returned memory, like GFP_DMA).
void *
dma_zalloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
Wraps dma_alloc_coherent() and also zeroes the returned memory if the
allocation attempt succeeded.
void void
dma_free_coherent(struct device *dev, size_t size, void *cpu_addr, dma_free_coherent(struct device *dev, size_t size, void *cpu_addr,
dma_addr_t dma_handle) dma_addr_t dma_handle)
......
...@@ -2486,6 +2486,9 @@ ioctls.</para> ...@@ -2486,6 +2486,9 @@ ioctls.</para>
<listitem> <listitem>
<para>Flash API. <xref linkend="flash-controls" /></para> <para>Flash API. <xref linkend="flash-controls" /></para>
</listitem> </listitem>
<listitem>
<para>&VIDIOC-CREATE-BUFS; and &VIDIOC-PREPARE-BUF; ioctls.</para>
</listitem>
</itemizedlist> </itemizedlist>
</section> </section>
......
...@@ -232,8 +232,9 @@ control is deprecated. New drivers and applications should use the ...@@ -232,8 +232,9 @@ control is deprecated. New drivers and applications should use the
<entry>Enables a power line frequency filter to avoid <entry>Enables a power line frequency filter to avoid
flicker. Possible values for <constant>enum v4l2_power_line_frequency</constant> are: flicker. Possible values for <constant>enum v4l2_power_line_frequency</constant> are:
<constant>V4L2_CID_POWER_LINE_FREQUENCY_DISABLED</constant> (0), <constant>V4L2_CID_POWER_LINE_FREQUENCY_DISABLED</constant> (0),
<constant>V4L2_CID_POWER_LINE_FREQUENCY_50HZ</constant> (1) and <constant>V4L2_CID_POWER_LINE_FREQUENCY_50HZ</constant> (1),
<constant>V4L2_CID_POWER_LINE_FREQUENCY_60HZ</constant> (2).</entry> <constant>V4L2_CID_POWER_LINE_FREQUENCY_60HZ</constant> (2) and
<constant>V4L2_CID_POWER_LINE_FREQUENCY_AUTO</constant> (3).</entry>
</row> </row>
<row> <row>
<entry><constant>V4L2_CID_HUE_AUTO</constant></entry> <entry><constant>V4L2_CID_HUE_AUTO</constant></entry>
......
...@@ -927,6 +927,33 @@ ioctl is called.</entry> ...@@ -927,6 +927,33 @@ ioctl is called.</entry>
Applications set or clear this flag before calling the Applications set or clear this flag before calling the
<constant>VIDIOC_QBUF</constant> ioctl.</entry> <constant>VIDIOC_QBUF</constant> ioctl.</entry>
</row> </row>
<row>
<entry><constant>V4L2_BUF_FLAG_PREPARED</constant></entry>
<entry>0x0400</entry>
<entry>The buffer has been prepared for I/O and can be queued by the
application. Drivers set or clear this flag when the
<link linkend="vidioc-querybuf">VIDIOC_QUERYBUF</link>, <link
linkend="vidioc-qbuf">VIDIOC_PREPARE_BUF</link>, <link
linkend="vidioc-qbuf">VIDIOC_QBUF</link> or <link
linkend="vidioc-qbuf">VIDIOC_DQBUF</link> ioctl is called.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant></entry>
<entry>0x0400</entry>
<entry>Caches do not have to be invalidated for this buffer.
Typically applications shall use this flag if the data captured in the buffer
is not going to be touched by the CPU, instead the buffer will, probably, be
passed on to a DMA-capable hardware unit for further processing or output.
</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant></entry>
<entry>0x0800</entry>
<entry>Caches do not have to be cleaned for this buffer.
Typically applications shall use this flag for output buffers if the data
in this buffer has not been created by the CPU but by some DMA-capable unit,
in which case caches have not been used.</entry>
</row>
</tbody> </tbody>
</tgroup> </tgroup>
</table> </table>
......
...@@ -469,6 +469,7 @@ and discussions on the V4L mailing list.</revremark> ...@@ -469,6 +469,7 @@ and discussions on the V4L mailing list.</revremark>
&sub-close; &sub-close;
&sub-ioctl; &sub-ioctl;
<!-- All ioctls go here. --> <!-- All ioctls go here. -->
&sub-create-bufs;
&sub-cropcap; &sub-cropcap;
&sub-dbg-g-chip-ident; &sub-dbg-g-chip-ident;
&sub-dbg-g-register; &sub-dbg-g-register;
...@@ -511,6 +512,7 @@ and discussions on the V4L mailing list.</revremark> ...@@ -511,6 +512,7 @@ and discussions on the V4L mailing list.</revremark>
&sub-queryctrl; &sub-queryctrl;
&sub-query-dv-preset; &sub-query-dv-preset;
&sub-querystd; &sub-querystd;
&sub-prepare-buf;
&sub-reqbufs; &sub-reqbufs;
&sub-s-hw-freq-seek; &sub-s-hw-freq-seek;
&sub-streamon; &sub-streamon;
......
<refentry id="vidioc-create-bufs">
<refmeta>
<refentrytitle>ioctl VIDIOC_CREATE_BUFS</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_CREATE_BUFS</refname>
<refpurpose>Create buffers for Memory Mapped or User Pointer I/O</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>struct v4l2_create_buffers *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>VIDIOC_CREATE_BUFS</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>This ioctl is used to create buffers for <link linkend="mmap">memory
mapped</link> or <link linkend="userp">user pointer</link>
I/O. It can be used as an alternative or in addition to the
<constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter control over buffers
is required. This ioctl can be called multiple times to create buffers of
different sizes.</para>
<para>To allocate device buffers applications initialize relevant fields of
the <structname>v4l2_create_buffers</structname> structure. They set the
<structfield>type</structfield> field in the
<structname>v4l2_format</structname> structure, embedded in this
structure, to the respective stream or buffer type.
<structfield>count</structfield> must be set to the number of required buffers.
<structfield>memory</structfield> specifies the required I/O method. The
<structfield>format</structfield> field shall typically be filled in using
either the <constant>VIDIOC_TRY_FMT</constant> or
<constant>VIDIOC_G_FMT</constant> ioctl(). Additionally, applications can adjust
<structfield>sizeimage</structfield> fields to fit their specific needs. The
<structfield>reserved</structfield> array must be zeroed.</para>
<para>When the ioctl is called with a pointer to this structure the driver
will attempt to allocate up to the requested number of buffers and store the
actual number allocated and the starting index in the
<structfield>count</structfield> and the <structfield>index</structfield> fields
respectively. On return <structfield>count</structfield> can be smaller than
the number requested. The driver may also increase buffer sizes if required,
however, it will not update <structfield>sizeimage</structfield> field values.
The user has to use <constant>VIDIOC_QUERYBUF</constant> to retrieve that
information.</para>
<table pgwide="1" frame="none" id="v4l2-create-buffers">
<title>struct <structname>v4l2_create_buffers</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>index</structfield></entry>
<entry>The starting buffer index, returned by the driver.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>count</structfield></entry>
<entry>The number of buffers requested or granted.</entry>
</row>
<row>
<entry>&v4l2-memory;</entry>
<entry><structfield>memory</structfield></entry>
<entry>Applications set this field to
<constant>V4L2_MEMORY_MMAP</constant> or
<constant>V4L2_MEMORY_USERPTR</constant>.</entry>
</row>
<row>
<entry>&v4l2-format;</entry>
<entry><structfield>format</structfield></entry>
<entry>Filled in by the application, preserved by the driver.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[8]</entry>
<entry>A place holder for future extensions.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>ENOMEM</errorcode></term>
<listitem>
<para>No memory to allocate buffers for <link linkend="mmap">memory
mapped</link> I/O.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The buffer type (<structfield>type</structfield> field) or the
requested I/O method (<structfield>memory</structfield>) is not
supported.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
<refentry id="vidioc-prepare-buf">
<refmeta>
<refentrytitle>ioctl VIDIOC_PREPARE_BUF</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_PREPARE_BUF</refname>
<refpurpose>Prepare a buffer for I/O</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>struct v4l2_buffer *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>VIDIOC_PREPARE_BUF</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>Applications can optionally call the
<constant>VIDIOC_PREPARE_BUF</constant> ioctl to pass ownership of the buffer
to the driver before actually enqueuing it, using the
<constant>VIDIOC_QBUF</constant> ioctl, and to prepare it for future I/O.
Such preparations may include cache invalidation or cleaning. Performing them
in advance saves time during the actual I/O. In case such cache operations are
not required, the application can use one of
<constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant> and
<constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant> flags to skip the respective
step.</para>
<para>The <structname>v4l2_buffer</structname> structure is
specified in <xref linkend="buffer" />.</para>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
<para>File I/O is in progress.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The buffer <structfield>type</structfield> is not
supported, or the <structfield>index</structfield> is out of bounds,
or no buffers have been allocated yet, or the
<structfield>userptr</structfield> or
<structfield>length</structfield> are invalid.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
To choose IO schedulers at boot time, use the argument 'elevator=deadline'. To choose IO schedulers at boot time, use the argument 'elevator=deadline'.
'noop', 'as' and 'cfq' (the default) are also available. IO schedulers are 'noop' and 'cfq' (the default) are also available. IO schedulers are assigned
assigned globally at boot time only presently. globally at boot time only presently.
Each io queue has a set of io scheduler tunables associated with it. These Each io queue has a set of io scheduler tunables associated with it. These
tunables control how the io scheduler works. You can find these entries tunables control how the io scheduler works. You can find these entries
......
...@@ -78,6 +78,16 @@ The device naming scheme is: ...@@ -78,6 +78,16 @@ The device naming scheme is:
/dev/cciss/c1d1p2 Controller 1, disk 1, partition 2 /dev/cciss/c1d1p2 Controller 1, disk 1, partition 2
/dev/cciss/c1d1p3 Controller 1, disk 1, partition 3 /dev/cciss/c1d1p3 Controller 1, disk 1, partition 3
CCISS simple mode support
-------------------------
The "cciss_simple_mode=1" boot parameter may be used to prevent the driver
from putting the controller into "performant" mode. The difference is that
with simple mode, each command completion requires an interrupt, while with
"performant mode" (the default, and ordinarily better performing) it is
possible to have multiple command completions indicated by a single
interrupt.
SCSI tape drive and medium changer support SCSI tape drive and medium changer support
------------------------------------------ ------------------------------------------
......
...@@ -454,8 +454,8 @@ mounted hierarchy, to remove a task from its current cgroup you must ...@@ -454,8 +454,8 @@ mounted hierarchy, to remove a task from its current cgroup you must
move it into a new cgroup (possibly the root cgroup) by writing to the move it into a new cgroup (possibly the root cgroup) by writing to the
new cgroup's tasks file. new cgroup's tasks file.
Note: If the ns cgroup is active, moving a process to another cgroup can Note: Due to some restrictions enforced by some cgroup subsystems, moving
fail. a process to another cgroup can fail.
2.3 Mounting hierarchies by name 2.3 Mounting hierarchies by name
-------------------------------- --------------------------------
......
...@@ -418,7 +418,6 @@ total_unevictable - sum of all children's "unevictable" ...@@ -418,7 +418,6 @@ total_unevictable - sum of all children's "unevictable"
# The following additional stats are dependent on CONFIG_DEBUG_VM. # The following additional stats are dependent on CONFIG_DEBUG_VM.
inactive_ratio - VM internal parameter. (see mm/page_alloc.c)
recent_rotated_anon - VM internal parameter. (see mm/vmscan.c) recent_rotated_anon - VM internal parameter. (see mm/vmscan.c)
recent_rotated_file - VM internal parameter. (see mm/vmscan.c) recent_rotated_file - VM internal parameter. (see mm/vmscan.c)
recent_scanned_anon - VM internal parameter. (see mm/vmscan.c) recent_scanned_anon - VM internal parameter. (see mm/vmscan.c)
......
...@@ -48,7 +48,7 @@ kernel and userspace, 'connector' is used as the interface for ...@@ -48,7 +48,7 @@ kernel and userspace, 'connector' is used as the interface for
communication. communication.
There are currently two userspace log implementations that leverage this There are currently two userspace log implementations that leverage this
framework - "clustered_disk" and "clustered_core". These implementations framework - "clustered-disk" and "clustered-core". These implementations
provide a cluster-coherent log for shared-storage. Device-mapper mirroring provide a cluster-coherent log for shared-storage. Device-mapper mirroring
can be used in a shared-storage environment when the cluster log implementations can be used in a shared-storage environment when the cluster log implementations
are employed. are employed.
Introduction
============
The more-sophisticated device-mapper targets require complex metadata
that is managed in kernel. In late 2010 we were seeing that various
different targets were rolling their own data strutures, for example:
- Mikulas Patocka's multisnap implementation
- Heinz Mauelshagen's thin provisioning target
- Another btree-based caching target posted to dm-devel
- Another multi-snapshot target based on a design of Daniel Phillips
Maintaining these data structures takes a lot of work, so if possible
we'd like to reduce the number.
The persistent-data library is an attempt to provide a re-usable
framework for people who want to store metadata in device-mapper
targets. It's currently used by the thin-provisioning target and an
upcoming hierarchical storage target.
Overview
========
The main documentation is in the header files which can all be found
under drivers/md/persistent-data.
The block manager
-----------------
dm-block-manager.[hc]
This provides access to the data on disk in fixed sized-blocks. There
is a read/write locking interface to prevent concurrent accesses, and
keep data that is being used in the cache.
Clients of persistent-data are unlikely to use this directly.
The transaction manager
-----------------------
dm-transaction-manager.[hc]
This restricts access to blocks and enforces copy-on-write semantics.
The only way you can get hold of a writable block through the
transaction manager is by shadowing an existing block (ie. doing
copy-on-write) or allocating a fresh one. Shadowing is elided within
the same transaction so performance is reasonable. The commit method
ensures that all data is flushed before it writes the superblock.
On power failure your metadata will be as it was when last committed.
The Space Maps
--------------
dm-space-map.h
dm-space-map-metadata.[hc]
dm-space-map-disk.[hc]
On-disk data structures that keep track of reference counts of blocks.
Also acts as the allocator of new blocks. Currently two
implementations: a simpler one for managing blocks on a different
device (eg. thinly-provisioned data blocks); and one for managing
the metadata space. The latter is complicated by the need to store
its own data within the space it's managing.
The data structures
-------------------
dm-btree.[hc]
dm-btree-remove.c
dm-btree-spine.c
dm-btree-internal.h
Currently there is only one data structure, a hierarchical btree.
There are plans to add more. For example, something with an
array-like interface would see a lot of use.
The btree is 'hierarchical' in that you can define it to be composed
of nested btrees, and take multiple keys. For example, the
thin-provisioning target uses a btree with two levels of nesting.
The first maps a device id to a mapping tree, and that in turn maps a
virtual block to a physical block.
Values stored in the btrees can have arbitrary size. Keys are always
64bits, although nesting allows you to use multiple keys.
Introduction
============
This document descibes a collection of device-mapper targets that
between them implement thin-provisioning and snapshots.
The main highlight of this implementation, compared to the previous
implementation of snapshots, is that it allows many virtual devices to
be stored on the same data volume. This simplifies administration and
allows the sharing of data between volumes, thus reducing disk usage.
Another significant feature is support for an arbitrary depth of
recursive snapshots (snapshots of snapshots of snapshots ...). The
previous implementation of snapshots did this by chaining together
lookup tables, and so performance was O(depth). This new
implementation uses a single data structure to avoid this degradation
with depth. Fragmentation may still be an issue, however, in some
scenarios.
Metadata is stored on a separate device from data, giving the
administrator some freedom, for example to:
- Improve metadata resilience by storing metadata on a mirrored volume
but data on a non-mirrored one.
- Improve performance by storing the metadata on SSD.
Status
======
These targets are very much still in the EXPERIMENTAL state. Please
do not yet rely on them in production. But do experiment and offer us
feedback. Different use cases will have different performance
characteristics, for example due to fragmentation of the data volume.
If you find this software is not performing as expected please mail
dm-devel@redhat.com with details and we'll try our best to improve
things for you.
Userspace tools for checking and repairing the metadata are under
development.
Cookbook
========
This section describes some quick recipes for using thin provisioning.
They use the dmsetup program to control the device-mapper driver
directly. End users will be advised to use a higher-level volume
manager such as LVM2 once support has been added.
Pool device
-----------
The pool device ties together the metadata volume and the data volume.
It maps I/O linearly to the data volume and updates the metadata via
two mechanisms:
- Function calls from the thin targets
- Device-mapper 'messages' from userspace which control the creation of new
virtual devices amongst other things.
Setting up a fresh pool device
------------------------------
Setting up a pool device requires a valid metadata device, and a
data device. If you do not have an existing metadata device you can
make one by zeroing the first 4k to indicate empty metadata.
dd if=/dev/zero of=$metadata_dev bs=4096 count=1
The amount of metadata you need will vary according to how many blocks
are shared between thin devices (i.e. through snapshots). If you have
less sharing than average you'll need a larger-than-average metadata device.
As a guide, we suggest you calculate the number of bytes to use in the
metadata device as 48 * $data_dev_size / $data_block_size but round it up