Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history 
yaml
---
r: 360613
b: refs/heads/master
c: 302a3c0
h: refs/heads/master
i:
  360611: 230964b
v: v3
  • Loading branch information
K. Y. Srinivasan authored and Greg Kroah-Hartman committed Feb 27, 2013
1 parent 1d3f075 commit 0b4cc6f
Show file tree
Hide file tree
Showing 2,158 changed files with 33,975 additions and 84,751 deletions.
2 changes: 1 addition & 1 deletion [refs]
View file
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: bc2e4a90d9f75f1664c1587eb09ecd10bb71b022
refs/heads/master: 302a3c0f2757ae1a3e7df3f9fa1f20e2214ab945
45 changes: 3 additions & 42 deletions trunk/Documentation/ABI/testing/sysfs-bus-fcoe
View file
Original file line number Diff line number Diff line change
@@ -1,53 +1,14 @@
What: /sys/bus/fcoe/
Date: August 2012
KernelVersion: TBD
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
Description: The FCoE bus. Attributes in this directory are control interfaces.
Attributes:

ctlr_create: 'FCoE Controller' instance creation interface. Writing an
<ifname> to this file will allocate and populate sysfs with a
fcoe_ctlr_device (ctlr_X). The user can then configure any
per-port settings and finally write to the fcoe_ctlr_device's
'start' attribute to begin the kernel's discovery and login
process.

ctlr_destroy: 'FCoE Controller' instance removal interface. Writing a
fcoe_ctlr_device's sysfs name to this file will log the
fcoe_ctlr_device out of the fabric or otherwise connected
FCoE devices. It will also free all kernel memory allocated
for this fcoe_ctlr_device and any structures associated
with it, this includes the scsi_host.

What: /sys/bus/fcoe/devices/ctlr_X
What: /sys/bus/fcoe/ctlr_X
Date: March 2012
KernelVersion: TBD
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
Description: 'FCoE Controller' instances on the fcoe bus.
The FCoE Controller now has a three stage creation process.
1) Write interface name to ctlr_create 2) Configure the FCoE
Controller (ctlr_X) 3) Enable the FCoE Controller to begin
discovery and login. The FCoE Controller is destroyed by
writing it's name, i.e. ctlr_X to the ctlr_delete file.

Description: 'FCoE Controller' instances on the fcoe bus
Attributes:

fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
this value will change the dev_loss_tmo for all
FCFs discovered by this controller.

mode: Display or change the FCoE Controller's mode. Possible
modes are 'Fabric' and 'VN2VN'. If a FCoE Controller
is started in 'Fabric' mode then FIP FCF discovery is
initiated and ultimately a fabric login is attempted.
If a FCoE Controller is started in 'VN2VN' mode then
FIP VN2VN discovery and login is performed. A FCoE
Controller only supports one mode at a time.

enabled: Whether an FCoE controller is enabled or disabled.
0 if disabled, 1 if enabled. Writing either 0 or 1
to this file will enable or disable the FCoE controller.

lesb/link_fail: Link Error Status Block (LESB) link failure count.

lesb/vlink_fail: Link Error Status Block (LESB) virtual link
Expand All @@ -65,7 +26,7 @@ Attributes:

Notes: ctlr_X (global increment starting at 0)

What: /sys/bus/fcoe/devices/fcf_X
What: /sys/bus/fcoe/fcf_X
Date: March 2012
KernelVersion: TBD
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
Expand Down
83 changes: 0 additions & 83 deletions trunk/Documentation/ABI/testing/sysfs-platform-msi-laptop
View file

This file was deleted.

9 changes: 4 additions & 5 deletions trunk/Documentation/DMA-API-HOWTO.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -488,10 +488,9 @@ will invoke the generic mapping error check interface. Doing so will ensure
that the mapping code will work correctly on all dma implementations without
any dependency on the specifics of the underlying implementation. Using the
returned address without checking for errors could result in failures ranging
from panics to silent data corruption. A couple of examples of incorrect ways
to check for errors that make assumptions about the underlying dma
implementation are as follows and these are applicable to dma_map_page() as
well.
from panics to silent data corruption. Couple of example of incorrect ways to
check for errors that make assumptions about the underlying dma implementation
are as follows and these are applicable to dma_map_page() as well.

Incorrect example 1:
dma_addr_t dma_handle;
Expand Down Expand Up @@ -752,7 +751,7 @@ Example 1:
dma_unmap_single(dma_handle1);
map_error_handling1:

Example 2: (if buffers are allocated in a loop, unmap all mapped buffers when
Example 2: (if buffers are allocated a loop, unmap all mapped buffers when
mapping error is detected in the middle)

dma_addr_t dma_addr;
Expand Down
18 changes: 6 additions & 12 deletions trunk/Documentation/IPMI.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -348,40 +348,34 @@ You can change this at module load time (for a module) with:

modprobe ipmi_si.o type=<type1>,<type2>....
ports=<port1>,<port2>... addrs=<addr1>,<addr2>...
irqs=<irq1>,<irq2>...
irqs=<irq1>,<irq2>... trydefaults=[0|1]
regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,...
regshifts=<shift1>,<shift2>,...
slave_addrs=<addr1>,<addr2>,...
force_kipmid=<enable1>,<enable2>,...
kipmid_max_busy_us=<ustime1>,<ustime2>,...
unload_when_empty=[0|1]
trydefaults=[0|1] trydmi=[0|1] tryacpi=[0|1]
tryplatform=[0|1] trypci=[0|1]

Each of these except try... items is a list, the first item for the
Each of these except si_trydefaults is a list, the first item for the
first interface, second item for the second interface, etc.

The si_type may be either "kcs", "smic", or "bt". If you leave it blank, it
defaults to "kcs".

If you specify addrs as non-zero for an interface, the driver will
If you specify si_addrs as non-zero for an interface, the driver will
use the memory address given as the address of the device. This
overrides si_ports.

If you specify ports as non-zero for an interface, the driver will
If you specify si_ports as non-zero for an interface, the driver will
use the I/O port given as the device address.

If you specify irqs as non-zero for an interface, the driver will
If you specify si_irqs as non-zero for an interface, the driver will
attempt to use the given interrupt for the device.

trydefaults sets whether the standard IPMI interface at 0xca2 and
si_trydefaults sets whether the standard IPMI interface at 0xca2 and
any interfaces specified by ACPE are tried. By default, the driver
tries it, set this value to zero to turn this off.

The other try... items disable discovery by their corresponding
names. These are all enabled by default, set them to zero to disable
them. The tryplatform disables openfirmware.

The next three parameters have to do with register layout. The
registers used by the interfaces may not appear at successive
locations and they may not be in 8-bit registers. These parameters
Expand Down
58 changes: 0 additions & 58 deletions trunk/Documentation/block/cfq-iosched.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -102,64 +102,6 @@ processing of request. Therefore, increasing the value can imporve the
performace although this can cause the latency of some I/O to increase due
to more number of requests.

CFQ Group scheduling
====================

CFQ supports blkio cgroup and has "blkio." prefixed files in each
blkio cgroup directory. It is weight-based and there are four knobs
for configuration - weight[_device] and leaf_weight[_device].
Internal cgroup nodes (the ones with children) can also have tasks in
them, so the former two configure how much proportion the cgroup as a
whole is entitled to at its parent's level while the latter two
configure how much proportion the tasks in the cgroup have compared to
its direct children.

Another way to think about it is assuming that each internal node has
an implicit leaf child node which hosts all the tasks whose weight is
configured by leaf_weight[_device]. Let's assume a blkio hierarchy
composed of five cgroups - root, A, B, AA and AB - with the following
weights where the names represent the hierarchy.

weight leaf_weight
root : 125 125
A : 500 750
B : 250 500
AA : 500 500
AB : 1000 500

root never has a parent making its weight is meaningless. For backward
compatibility, weight is always kept in sync with leaf_weight. B, AA
and AB have no child and thus its tasks have no children cgroup to
compete with. They always get 100% of what the cgroup won at the
parent level. Considering only the weights which matter, the hierarchy
looks like the following.

root
/ | \
A B leaf
500 250 125
/ | \
AA AB leaf
500 1000 750

If all cgroups have active IOs and competing with each other, disk
time will be distributed like the following.

Distribution below root. The total active weight at this level is
A:500 + B:250 + C:125 = 875.

root-leaf : 125 / 875 =~ 14%
A : 500 / 875 =~ 57%
B(-leaf) : 250 / 875 =~ 28%

A has children and further distributes its 57% among the children and
the implicit leaf node. The total active weight at this level is
AA:500 + AB:1000 + A-leaf:750 = 2250.

A-leaf : ( 750 / 2250) * A =~ 19%
AA(-leaf) : ( 500 / 2250) * A =~ 12%
AB(-leaf) : (1000 / 2250) * A =~ 25%

CFQ IOPS Mode for group scheduling
===================================
Basic CFQ design is to provide priority based time slices. Higher priority
Expand Down
38 changes: 34 additions & 4 deletions trunk/Documentation/blockdev/nbd.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,13 +4,43 @@
can use a remote server as one of its block devices. So every time
the client computer wants to read, e.g., /dev/nb0, it sends a
request over TCP to the server, which will reply with the data read.
This can be used for stations with low disk space (or even diskless)
to borrow disk space from another computer.
Unlike NFS, it is possible to put any filesystem on it, etc.

This can be used for stations with low disk space (or even diskless -
if you boot from floppy) to borrow disk space from another computer.
Unlike NFS, it is possible to put any filesystem on it, etc. It should
even be possible to use NBD as a root filesystem (I've never tried),
but it requires a user-level program to be in the initrd to start.
It also allows you to run block-device in user land (making server
and client physically the same computer, communicating using loopback).

Current state: It currently works. Network block device is stable.
I originally thought that it was impossible to swap over TCP. It
turned out not to be true - swapping over TCP now works and seems
to be deadlock-free, but it requires heavy patches into Linux's
network layer.

For more information, or to download the nbd-client and nbd-server
tools, go to http://nbd.sf.net/.

Howto: To setup nbd, you can simply do the following:

First, serve a device or file from a remote server:

nbd-server <port-number> <device-or-file-to-serve-to-client>

e.g.,
root@server1 # nbd-server 1234 /dev/sdb1

(serves sdb1 partition on TCP port 1234)

Then, on the local (client) system:

nbd-client <server-name-or-IP> <server-port-number> /dev/nb[0-n]

e.g.,
root@client1 # nbd-client server1 1234 /dev/nb0

(creates the nb0 device on client1)

The nbd kernel module need only be installed on the client
system, as the nbd-server is completely in userspace. In fact,
the nbd-server has been successfully ported to other operating
Expand Down
Loading

0 comments on commit 0b4cc6f

Please sign in to comment.