docs conversion for v5.3-rc1
-----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE+QmuaPwR3wnBdVwACF8+vY7k4RUFAl0tpocACgkQCF8+vY7k 4RWoxA//b/fmDXP3WPzrjjSmpyB9ml0/epKzPbT5S2j0lftqKBmet29k+PCjVrTx Nq2QauehY9ug5h8UMVUCmzPr95F0tSIGRoqk1vrn7z0K3q6k1SHrtvqbY1Bgb2Uk Qvh2YFU4fQLJg8WAbExCjxCdbdmBKQVGKTwCtM+tP5OMxwAFOmQrjGaUaKCKIIA2 7Wzrx8CpSji+bJ3uK/d36c+4M9oDly5eaxBhoboL3BI0y+GqwiSASGwTO7BxrPOg 0wq5IZHnqS8+bprT9xQdDOqf+UOY9U1cxE/+sqsHxblfUEx9gfLy/R+FLmJn+SS9 Z3yLy4SqVHQMpWBjEAGodohikF60PAuTdymSC11jqFaKCUxWrIZg5xO+0blMrxPF 7vYIexutCkaBMHBlNaNsHIqB7B/2FGGKoN7QW64hwvwJCGvF7OmJcV+R4bROGvh4 nFuis9/Nm66Fq7I3aw37ThyZ0aWZdaQ0QJTH9ksxU/ZCz2hhMNYu/rXggrDvkS4U nr77ZT5Gd7nj4b110zf8+99uiGiinY6hTfzPAuTCLBhaxwrv4/xDHAhpwdEB5T4j 8gOkxV8c0XWtL7sKqhGJvs/RRe2za0Y9XH6fyxsYfWcfuLjEvug8ouXMad9gxFWH DL3WnKJEMGLScei2wux4kGOwEbkR1bUf2cHJfh3GpCB/y8vgLOc= =smxY -----END PGP SIGNATURE----- Merge tag 'docs/v5.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull rst conversion of docs from Mauro Carvalho Chehab: "As agreed with Jon, I'm sending this big series directly to you, c/c him, as this series required a special care, in order to avoid conflicts with other trees" * tag 'docs/v5.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (77 commits) docs: kbuild: fix build with pdf and fix some minor issues docs: block: fix pdf output docs: arm: fix a breakage with pdf output docs: don't use nested tables docs: gpio: add sysfs interface to the admin-guide docs: locking: add it to the main index docs: add some directories to the main documentation index docs: add SPDX tags to new index files docs: add a memory-devices subdir to driver-api docs: phy: place documentation under driver-api docs: serial: move it to the driver-api docs: driver-api: add remaining converted dirs to it docs: driver-api: add xilinx driver API documentation docs: driver-api: add a series of orphaned documents docs: admin-guide: add a series of orphaned documents docs: cgroup-v1: add it to the admin-guide book docs: aoe: add it to the driver-api book docs: add some documentation dirs to the driver-api book docs: driver-model: move it to the driver-api book docs: lp855x-driver.rst: add it to the driver-api book ...
This commit is contained in:
commit
c309b6f242
2
CREDITS
2
CREDITS
|
@ -3120,7 +3120,7 @@ S: France
|
|||
N: Rik van Riel
|
||||
E: riel@redhat.com
|
||||
W: http://www.surriel.com/
|
||||
D: Linux-MM site, Documentation/sysctl/*, swap/mm readaround
|
||||
D: Linux-MM site, Documentation/admin-guide/sysctl/*, swap/mm readaround
|
||||
D: kswapd fixes, random kernel hacker, rmap VM,
|
||||
D: nl.linux.org administrator, minor scheduler additions
|
||||
S: Red Hat Boston
|
||||
|
|
|
@ -11,7 +11,7 @@ Description:
|
|||
Kernel code may export it for complete or partial access.
|
||||
|
||||
GPIOs are identified as they are inside the kernel, using integers in
|
||||
the range 0..INT_MAX. See Documentation/gpio for more information.
|
||||
the range 0..INT_MAX. See Documentation/admin-guide/gpio for more information.
|
||||
|
||||
/sys/class/gpio
|
||||
/export ... asks the kernel to export a GPIO to userspace
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
rfkill - radio frequency (RF) connector kill switch support
|
||||
|
||||
For details to this subsystem look at Documentation/rfkill.txt.
|
||||
For details to this subsystem look at Documentation/driver-api/rfkill.rst.
|
||||
|
||||
What: /sys/class/rfkill/rfkill[0-9]+/claim
|
||||
Date: 09-Jul-2007
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
rfkill - radio frequency (RF) connector kill switch support
|
||||
|
||||
For details to this subsystem look at Documentation/rfkill.txt.
|
||||
For details to this subsystem look at Documentation/driver-api/rfkill.rst.
|
||||
|
||||
For the deprecated /sys/class/rfkill/*/claim knobs of this interface look in
|
||||
Documentation/ABI/removed/sysfs-class-rfkill.
|
||||
|
|
|
@ -61,7 +61,7 @@ Date: October 2002
|
|||
Contact: Linux Memory Management list <linux-mm@kvack.org>
|
||||
Description:
|
||||
The node's hit/miss statistics, in units of pages.
|
||||
See Documentation/numastat.txt
|
||||
See Documentation/admin-guide/numastat.rst
|
||||
|
||||
What: /sys/devices/system/node/nodeX/distance
|
||||
Date: October 2002
|
||||
|
|
|
@ -29,4 +29,4 @@ Description:
|
|||
17 - sectors discarded
|
||||
18 - time spent discarding
|
||||
|
||||
For more details refer to Documentation/iostats.txt
|
||||
For more details refer to Documentation/admin-guide/iostats.rst
|
||||
|
|
|
@ -15,7 +15,7 @@ Description:
|
|||
9 - I/Os currently in progress
|
||||
10 - time spent doing I/Os (ms)
|
||||
11 - weighted time spent doing I/Os (ms)
|
||||
For more details refer Documentation/iostats.txt
|
||||
For more details refer Documentation/admin-guide/iostats.rst
|
||||
|
||||
|
||||
What: /sys/block/<disk>/<part>/stat
|
||||
|
|
|
@ -45,7 +45,7 @@ Description:
|
|||
- Values below -2 are rejected with -EINVAL
|
||||
|
||||
For more information, see
|
||||
Documentation/laptops/disk-shock-protection.txt
|
||||
Documentation/admin-guide/laptops/disk-shock-protection.rst
|
||||
|
||||
|
||||
What: /sys/block/*/device/ncq_prio_enable
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
switchtec - Microsemi Switchtec PCI Switch Management Endpoint
|
||||
|
||||
For details on this subsystem look at Documentation/switchtec.txt.
|
||||
For details on this subsystem look at Documentation/driver-api/switchtec.rst.
|
||||
|
||||
What: /sys/class/switchtec
|
||||
Date: 05-Jan-2017
|
||||
|
|
|
@ -34,7 +34,7 @@ Description: CPU topology files that describe kernel limits related to
|
|||
present: cpus that have been identified as being present in
|
||||
the system.
|
||||
|
||||
See Documentation/cputopology.txt for more information.
|
||||
See Documentation/admin-guide/cputopology.rst for more information.
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/probe
|
||||
|
@ -103,7 +103,7 @@ Description: CPU topology files that describe a logical CPU's relationship
|
|||
thread_siblings_list: human-readable list of cpu#'s hardware
|
||||
threads within the same core as cpu#
|
||||
|
||||
See Documentation/cputopology.txt for more information.
|
||||
See Documentation/admin-guide/cputopology.rst for more information.
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpuidle/current_driver
|
||||
|
|
|
@ -31,7 +31,7 @@ Description:
|
|||
To control the LED display, use the following :
|
||||
echo 0x0T000DDD > /sys/devices/platform/asus_laptop/
|
||||
where T control the 3 letters display, and DDD the 3 digits display.
|
||||
The DDD table can be found in Documentation/laptops/asus-laptop.txt
|
||||
The DDD table can be found in Documentation/admin-guide/laptops/asus-laptop.rst
|
||||
|
||||
What: /sys/devices/platform/asus_laptop/bluetooth
|
||||
Date: January 2007
|
||||
|
|
|
@ -212,7 +212,7 @@ The standard 64-bit addressing device would do something like this::
|
|||
|
||||
If the device only supports 32-bit addressing for descriptors in the
|
||||
coherent allocations, but supports full 64-bits for streaming mappings
|
||||
it would look like this:
|
||||
it would look like this::
|
||||
|
||||
if (dma_set_mask(dev, DMA_BIT_MASK(64))) {
|
||||
dev_warn(dev, "mydev: No suitable DMA available\n");
|
||||
|
|
|
@ -1,3 +1,7 @@
|
|||
==================
|
||||
Control Groupstats
|
||||
==================
|
||||
|
||||
Control Groupstats is inspired by the discussion at
|
||||
http://lkml.org/lkml/2007/4/11/187 and implements per cgroup statistics as
|
||||
suggested by Andrew Morton in http://lkml.org/lkml/2007/4/11/263.
|
||||
|
@ -19,9 +23,9 @@ about tasks blocked on I/O. If CONFIG_TASK_DELAY_ACCT is disabled, this
|
|||
information will not be available.
|
||||
|
||||
To extract cgroup statistics a utility very similar to getdelays.c
|
||||
has been developed, the sample output of the utility is shown below
|
||||
has been developed, the sample output of the utility is shown below::
|
||||
|
||||
~/balbir/cgroupstats # ./getdelays -C "/sys/fs/cgroup/a"
|
||||
sleeping 1, blocked 0, running 1, stopped 0, uninterruptible 0
|
||||
~/balbir/cgroupstats # ./getdelays -C "/sys/fs/cgroup"
|
||||
sleeping 155, blocked 0, running 1, stopped 0, uninterruptible 2
|
||||
~/balbir/cgroupstats # ./getdelays -C "/sys/fs/cgroup/a"
|
||||
sleeping 1, blocked 0, running 1, stopped 0, uninterruptible 0
|
||||
~/balbir/cgroupstats # ./getdelays -C "/sys/fs/cgroup"
|
||||
sleeping 155, blocked 0, running 1, stopped 0, uninterruptible 2
|
|
@ -1,5 +1,6 @@
|
|||
================
|
||||
Delay accounting
|
||||
----------------
|
||||
================
|
||||
|
||||
Tasks encounter delays in execution when they wait
|
||||
for some kernel resource to become available e.g. a
|
||||
|
@ -39,7 +40,9 @@ in detail in a separate document in this directory. Taskstats returns a
|
|||
generic data structure to userspace corresponding to per-pid and per-tgid
|
||||
statistics. The delay accounting functionality populates specific fields of
|
||||
this structure. See
|
||||
|
||||
include/linux/taskstats.h
|
||||
|
||||
for a description of the fields pertaining to delay accounting.
|
||||
It will generally be in the form of counters returning the cumulative
|
||||
delay seen for cpu, sync block I/O, swapin, memory reclaim etc.
|
||||
|
@ -61,13 +64,16 @@ also serves as an example of using the taskstats interface.
|
|||
Usage
|
||||
-----
|
||||
|
||||
Compile the kernel with
|
||||
Compile the kernel with::
|
||||
|
||||
CONFIG_TASK_DELAY_ACCT=y
|
||||
CONFIG_TASKSTATS=y
|
||||
|
||||
Delay accounting is enabled by default at boot up.
|
||||
To disable, add
|
||||
To disable, add::
|
||||
|
||||
nodelayacct
|
||||
|
||||
to the kernel boot options. The rest of the instructions
|
||||
below assume this has not been done.
|
||||
|
||||
|
@ -78,40 +84,43 @@ The utility also allows a given command to be
|
|||
executed and the corresponding delays to be
|
||||
seen.
|
||||
|
||||
General format of the getdelays command
|
||||
General format of the getdelays command::
|
||||
|
||||
getdelays [-t tgid] [-p pid] [-c cmd...]
|
||||
getdelays [-t tgid] [-p pid] [-c cmd...]
|
||||
|
||||
|
||||
Get delays, since system boot, for pid 10
|
||||
# ./getdelays -p 10
|
||||
(output similar to next case)
|
||||
Get delays, since system boot, for pid 10::
|
||||
|
||||
Get sum of delays, since system boot, for all pids with tgid 5
|
||||
# ./getdelays -t 5
|
||||
# ./getdelays -p 10
|
||||
(output similar to next case)
|
||||
|
||||
Get sum of delays, since system boot, for all pids with tgid 5::
|
||||
|
||||
# ./getdelays -t 5
|
||||
|
||||
|
||||
CPU count real total virtual total delay total
|
||||
7876 92005750 100000000 24001500
|
||||
IO count delay total
|
||||
0 0
|
||||
SWAP count delay total
|
||||
0 0
|
||||
RECLAIM count delay total
|
||||
0 0
|
||||
CPU count real total virtual total delay total
|
||||
7876 92005750 100000000 24001500
|
||||
IO count delay total
|
||||
0 0
|
||||
SWAP count delay total
|
||||
0 0
|
||||
RECLAIM count delay total
|
||||
0 0
|
||||
|
||||
Get delays seen in executing a given simple command
|
||||
# ./getdelays -c ls /
|
||||
Get delays seen in executing a given simple command::
|
||||
|
||||
bin data1 data3 data5 dev home media opt root srv sys usr
|
||||
boot data2 data4 data6 etc lib mnt proc sbin subdomain tmp var
|
||||
# ./getdelays -c ls /
|
||||
|
||||
bin data1 data3 data5 dev home media opt root srv sys usr
|
||||
boot data2 data4 data6 etc lib mnt proc sbin subdomain tmp var
|
||||
|
||||
|
||||
CPU count real total virtual total delay total
|
||||
CPU count real total virtual total delay total
|
||||
6 4000250 4000000 0
|
||||
IO count delay total
|
||||
IO count delay total
|
||||
0 0
|
||||
SWAP count delay total
|
||||
SWAP count delay total
|
||||
0 0
|
||||
RECLAIM count delay total
|
||||
RECLAIM count delay total
|
||||
0 0
|
|
@ -0,0 +1,14 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
==========
|
||||
Accounting
|
||||
==========
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
cgroupstats
|
||||
delay-accounting
|
||||
psi
|
||||
taskstats
|
||||
taskstats-struct
|
|
@ -35,14 +35,14 @@ Pressure interface
|
|||
Pressure information for each resource is exported through the
|
||||
respective file in /proc/pressure/ -- cpu, memory, and io.
|
||||
|
||||
The format for CPU is as such:
|
||||
The format for CPU is as such::
|
||||
|
||||
some avg10=0.00 avg60=0.00 avg300=0.00 total=0
|
||||
some avg10=0.00 avg60=0.00 avg300=0.00 total=0
|
||||
|
||||
and for memory and IO:
|
||||
and for memory and IO::
|
||||
|
||||
some avg10=0.00 avg60=0.00 avg300=0.00 total=0
|
||||
full avg10=0.00 avg60=0.00 avg300=0.00 total=0
|
||||
some avg10=0.00 avg60=0.00 avg300=0.00 total=0
|
||||
full avg10=0.00 avg60=0.00 avg300=0.00 total=0
|
||||
|
||||
The "some" line indicates the share of time in which at least some
|
||||
tasks are stalled on a given resource.
|
||||
|
@ -77,9 +77,9 @@ To register a trigger user has to open psi interface file under
|
|||
/proc/pressure/ representing the resource to be monitored and write the
|
||||
desired threshold and time window. The open file descriptor should be
|
||||
used to wait for trigger events using select(), poll() or epoll().
|
||||
The following format is used:
|
||||
The following format is used::
|
||||
|
||||
<some|full> <stall amount in us> <time window in us>
|
||||
<some|full> <stall amount in us> <time window in us>
|
||||
|
||||
For example writing "some 150000 1000000" into /proc/pressure/memory
|
||||
would add 150ms threshold for partial memory stall measured within
|
||||
|
@ -115,18 +115,20 @@ trigger is closed.
|
|||
Userspace monitor usage example
|
||||
===============================
|
||||
|
||||
#include <errno.h>
|
||||
#include <fcntl.h>
|
||||
#include <stdio.h>
|
||||
#include <poll.h>
|
||||
#include <string.h>
|
||||
#include <unistd.h>
|
||||
::
|
||||
|
||||
/*
|
||||
* Monitor memory partial stall with 1s tracking window size
|
||||
* and 150ms threshold.
|
||||
*/
|
||||
int main() {
|
||||
#include <errno.h>
|
||||
#include <fcntl.h>
|
||||
#include <stdio.h>
|
||||
#include <poll.h>
|
||||
#include <string.h>
|
||||
#include <unistd.h>
|
||||
|
||||
/*
|
||||
* Monitor memory partial stall with 1s tracking window size
|
||||
* and 150ms threshold.
|
||||
*/
|
||||
int main() {
|
||||
const char trig[] = "some 150000 1000000";
|
||||
struct pollfd fds;
|
||||
int n;
|
||||
|
@ -165,7 +167,7 @@ int main() {
|
|||
}
|
||||
|
||||
return 0;
|
||||
}
|
||||
}
|
||||
|
||||
Cgroup2 interface
|
||||
=================
|
|
@ -1,5 +1,6 @@
|
|||
====================
|
||||
The struct taskstats
|
||||
--------------------
|
||||
====================
|
||||
|
||||
This document contains an explanation of the struct taskstats fields.
|
||||
|
||||
|
@ -10,16 +11,24 @@ There are three different groups of fields in the struct taskstats:
|
|||
the common fields and basic accounting fields are collected for
|
||||
delivery at do_exit() of a task.
|
||||
2) Delay accounting fields
|
||||
These fields are placed between
|
||||
/* Delay accounting fields start */
|
||||
and
|
||||
/* Delay accounting fields end */
|
||||
These fields are placed between::
|
||||
|
||||
/* Delay accounting fields start */
|
||||
|
||||
and::
|
||||
|
||||
/* Delay accounting fields end */
|
||||
|
||||
Their values are collected if CONFIG_TASK_DELAY_ACCT is set.
|
||||
3) Extended accounting fields
|
||||
These fields are placed between
|
||||
/* Extended accounting fields start */
|
||||
and
|
||||
/* Extended accounting fields end */
|
||||
These fields are placed between::
|
||||
|
||||
/* Extended accounting fields start */
|
||||
|
||||
and::
|
||||
|
||||
/* Extended accounting fields end */
|
||||
|
||||
Their values are collected if CONFIG_TASK_XACCT is set.
|
||||
|
||||
4) Per-task and per-thread context switch count statistics
|
||||
|
@ -31,31 +40,33 @@ There are three different groups of fields in the struct taskstats:
|
|||
Future extension should add fields to the end of the taskstats struct, and
|
||||
should not change the relative position of each field within the struct.
|
||||
|
||||
::
|
||||
|
||||
struct taskstats {
|
||||
struct taskstats {
|
||||
|
||||
1) Common and basic accounting fields::
|
||||
|
||||
1) Common and basic accounting fields:
|
||||
/* The version number of this struct. This field is always set to
|
||||
* TAKSTATS_VERSION, which is defined in <linux/taskstats.h>.
|
||||
* Each time the struct is changed, the value should be incremented.
|
||||
*/
|
||||
__u16 version;
|
||||
|
||||
/* The exit code of a task. */
|
||||
/* The exit code of a task. */
|
||||
__u32 ac_exitcode; /* Exit status */
|
||||
|
||||
/* The accounting flags of a task as defined in <linux/acct.h>
|
||||
/* The accounting flags of a task as defined in <linux/acct.h>
|
||||
* Defined values are AFORK, ASU, ACOMPAT, ACORE, and AXSIG.
|
||||
*/
|
||||
__u8 ac_flag; /* Record flags */
|
||||
|
||||
/* The value of task_nice() of a task. */
|
||||
/* The value of task_nice() of a task. */
|
||||
__u8 ac_nice; /* task_nice */
|
||||
|
||||
/* The name of the command that started this task. */
|
||||
/* The name of the command that started this task. */
|
||||
char ac_comm[TS_COMM_LEN]; /* Command name */
|
||||
|
||||
/* The scheduling discipline as set in task->policy field. */
|
||||
/* The scheduling discipline as set in task->policy field. */
|
||||
__u8 ac_sched; /* Scheduling discipline */
|
||||
|
||||
__u8 ac_pad[3];
|
||||
|
@ -64,26 +75,27 @@ struct taskstats {
|
|||
__u32 ac_pid; /* Process ID */
|
||||
__u32 ac_ppid; /* Parent process ID */
|
||||
|
||||
/* The time when a task begins, in [secs] since 1970. */
|
||||
/* The time when a task begins, in [secs] since 1970. */
|
||||
__u32 ac_btime; /* Begin time [sec since 1970] */
|
||||
|
||||
/* The elapsed time of a task, in [usec]. */
|
||||
/* The elapsed time of a task, in [usec]. */
|
||||
__u64 ac_etime; /* Elapsed time [usec] */
|
||||
|
||||
/* The user CPU time of a task, in [usec]. */
|
||||
/* The user CPU time of a task, in [usec]. */
|
||||
__u64 ac_utime; /* User CPU time [usec] */
|
||||
|
||||
/* The system CPU time of a task, in [usec]. */
|
||||
/* The system CPU time of a task, in [usec]. */
|
||||
__u64 ac_stime; /* System CPU time [usec] */
|
||||
|
||||
/* The minor page fault count of a task, as set in task->min_flt. */
|
||||
/* The minor page fault count of a task, as set in task->min_flt. */
|
||||
__u64 ac_minflt; /* Minor Page Fault Count */
|
||||
|
||||
/* The major page fault count of a task, as set in task->maj_flt. */
|
||||
__u64 ac_majflt; /* Major Page Fault Count */
|
||||
|
||||
|
||||
2) Delay accounting fields:
|
||||
2) Delay accounting fields::
|
||||
|
||||
/* Delay accounting fields start
|
||||
*
|
||||
* All values, until the comment "Delay accounting fields end" are
|
||||
|
@ -134,7 +146,8 @@ struct taskstats {
|
|||
/* version 1 ends here */
|
||||
|
||||
|
||||
3) Extended accounting fields
|
||||
3) Extended accounting fields::
|
||||
|
||||
/* Extended accounting fields start */
|
||||
|
||||
/* Accumulated RSS usage in duration of a task, in MBytes-usecs.
|
||||
|
@ -145,15 +158,15 @@ struct taskstats {
|
|||
*/
|
||||
__u64 coremem; /* accumulated RSS usage in MB-usec */
|
||||
|
||||
/* Accumulated virtual memory usage in duration of a task.
|
||||
/* Accumulated virtual memory usage in duration of a task.
|
||||
* Same as acct_rss_mem1 above except that we keep track of VM usage.
|
||||
*/
|
||||
__u64 virtmem; /* accumulated VM usage in MB-usec */
|
||||
|
||||
/* High watermark of RSS usage in duration of a task, in KBytes. */
|
||||
/* High watermark of RSS usage in duration of a task, in KBytes. */
|
||||
__u64 hiwater_rss; /* High-watermark of RSS usage */
|
||||
|
||||
/* High watermark of VM usage in duration of a task, in KBytes. */
|
||||
/* High watermark of VM usage in duration of a task, in KBytes. */
|
||||
__u64 hiwater_vm; /* High-water virtual memory usage */
|
||||
|
||||
/* The following four fields are I/O statistics of a task. */
|
||||
|
@ -164,17 +177,23 @@ struct taskstats {
|
|||
|
||||
/* Extended accounting fields end */
|
||||
|
||||
4) Per-task and per-thread statistics
|
||||
4) Per-task and per-thread statistics::
|
||||
|
||||
__u64 nvcsw; /* Context voluntary switch counter */
|
||||
__u64 nivcsw; /* Context involuntary switch counter */
|
||||
|
||||
5) Time accounting for SMT machines
|
||||
5) Time accounting for SMT machines::
|
||||
|
||||
__u64 ac_utimescaled; /* utime scaled on frequency etc */
|
||||
__u64 ac_stimescaled; /* stime scaled on frequency etc */
|
||||
__u64 cpu_scaled_run_real_total; /* scaled cpu_run_real_total */
|
||||
|
||||
6) Extended delay accounting fields for memory reclaim
|
||||
6) Extended delay accounting fields for memory reclaim::
|
||||
|
||||
/* Delay waiting for memory reclaim */
|
||||
__u64 freepages_count;
|
||||
__u64 freepages_delay_total;
|
||||
}
|
||||
|
||||
::
|
||||
|
||||
}
|
|
@ -1,5 +1,6 @@
|
|||
=============================
|
||||
Per-task statistics interface
|
||||
-----------------------------
|
||||
=============================
|
||||
|
||||
|
||||
Taskstats is a netlink-based interface for sending per-task and
|
||||
|
@ -65,7 +66,7 @@ taskstats.h file.
|
|||
|
||||
The data exchanged between user and kernel space is a netlink message belonging
|
||||
to the NETLINK_GENERIC family and using the netlink attributes interface.
|
||||
The messages are in the format
|
||||
The messages are in the format::
|
||||
|
||||
+----------+- - -+-------------+-------------------+
|
||||
| nlmsghdr | Pad | genlmsghdr | taskstats payload |
|
||||
|
@ -167,15 +168,13 @@ extended and the number of cpus grows large.
|
|||
To avoid losing statistics, userspace should do one or more of the following:
|
||||
|
||||
- increase the receive buffer sizes for the netlink sockets opened by
|
||||
listeners to receive exit data.
|
||||
listeners to receive exit data.
|
||||
|
||||
- create more listeners and reduce the number of cpus being listened to by
|
||||
each listener. In the extreme case, there could be one listener for each cpu.
|
||||
Users may also consider setting the cpu affinity of the listener to the subset
|
||||
of cpus to which it listens, especially if they are listening to just one cpu.
|
||||
each listener. In the extreme case, there could be one listener for each cpu.
|
||||
Users may also consider setting the cpu affinity of the listener to the subset
|
||||
of cpus to which it listens, especially if they are listening to just one cpu.
|
||||
|
||||
Despite these measures, if the userspace receives ENOBUFS error messages
|
||||
indicated overflow of receive buffers, it should take measures to handle the
|
||||
loss of data.
|
||||
|
||||
----
|
|
@ -20,7 +20,7 @@ driver. The aoetools are on sourceforge.
|
|||
|
||||
http://aoetools.sourceforge.net/
|
||||
|
||||
The scripts in this Documentation/aoe directory are intended to
|
||||
The scripts in this Documentation/admin-guide/aoe directory are intended to
|
||||
document the use of the driver and are not necessary if you install
|
||||
the aoetools.
|
||||
|
||||
|
@ -86,7 +86,7 @@ Using sysfs
|
|||
a convenient way. Users with aoetools should use the aoe-stat
|
||||
command::
|
||||
|
||||
root@makki root# sh Documentation/aoe/status.sh
|
||||
root@makki root# sh Documentation/admin-guide/aoe/status.sh
|
||||
e10.0 eth3 up
|
||||
e10.1 eth3 up
|
||||
e10.2 eth3 up
|
|
@ -1,5 +1,3 @@
|
|||
:orphan:
|
||||
|
||||
=======================
|
||||
ATA over Ethernet (AoE)
|
||||
=======================
|
|
@ -11,7 +11,7 @@
|
|||
# udev_rules="/etc/udev/rules.d/"
|
||||
# bash# ls /etc/udev/rules.d/
|
||||
# 10-wacom.rules 50-udev.rules
|
||||
# bash# cp /path/to/linux/Documentation/aoe/udev.txt \
|
||||
# bash# cp /path/to/linux/Documentation/admin-guide/aoe/udev.txt \
|
||||
# /etc/udev/rules.d/60-aoe.rules
|
||||
#
|
||||
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 22 KiB |
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
|
@ -1,3 +1,7 @@
|
|||
================================
|
||||
kernel data structure for DRBD-9
|
||||
================================
|
||||
|
||||
This describes the in kernel data structure for DRBD-9. Starting with
|
||||
Linux v3.14 we are reorganizing DRBD to use this data structure.
|
||||
|
||||
|
@ -10,7 +14,7 @@ device is represented by a block device locally.
|
|||
|
||||
The DRBD objects are interconnected to form a matrix as depicted below; a
|
||||
drbd_peer_device object sits at each intersection between a drbd_device and a
|
||||
drbd_connection:
|
||||
drbd_connection::
|
||||
|
||||
/--------------+---------------+.....+---------------\
|
||||
| resource | device | | device |
|
|
@ -0,0 +1,30 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. The here included files are intended to help understand the implementation
|
||||
|
||||
Data flows that Relate some functions, and write packets
|
||||
========================================================
|
||||
|
||||
.. kernel-figure:: DRBD-8.3-data-packets.svg
|
||||
:alt: DRBD-8.3-data-packets.svg
|
||||
:align: center
|
||||
|
||||
.. kernel-figure:: DRBD-data-packets.svg
|
||||
:alt: DRBD-data-packets.svg
|
||||
:align: center
|
||||
|
||||
|
||||
Sub graphs of DRBD's state transitions
|
||||
======================================
|
||||
|
||||
.. kernel-figure:: conn-states-8.dot
|
||||
:alt: conn-states-8.dot
|
||||
:align: center
|
||||
|
||||
.. kernel-figure:: disk-states-8.dot
|
||||
:alt: disk-states-8.dot
|
||||
:align: center
|
||||
|
||||
.. kernel-figure:: node-states-8.dot
|
||||
:alt: node-states-8.dot
|
||||
:align: center
|
|
@ -1,4 +1,9 @@
|
|||
==========================================
|
||||
Distributed Replicated Block Device - DRBD
|
||||
==========================================
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
DRBD is a shared-nothing, synchronously replicated block device. It
|
||||
is designed to serve as a building block for high availability
|
||||
|
@ -7,10 +12,8 @@ Description
|
|||
|
||||
Please visit http://www.drbd.org to find out more.
|
||||
|
||||
The here included files are intended to help understand the implementation
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
DRBD-8.3-data-packets.svg, DRBD-data-packets.svg
|
||||
relates some functions, and write packets.
|
||||
|
||||
conn-states-8.dot, disk-states-8.dot, node-states-8.dot
|
||||
The sub graphs of DRBD's state transitions
|
||||
data-structure-v9
|
||||
figures
|
|
@ -11,4 +11,3 @@ digraph peer_states {
|
|||
Unknown -> Primary [ label = "connected" ]
|
||||
Unknown -> Secondary [ label = "connected" ]
|
||||
}
|
||||
|
|
@ -1,35 +1,37 @@
|
|||
This file describes the floppy driver.
|
||||
=============
|
||||
Floppy Driver
|
||||
=============
|
||||
|
||||
FAQ list:
|
||||
=========
|
||||
|
||||
A FAQ list may be found in the fdutils package (see below), and also
|
||||
A FAQ list may be found in the fdutils package (see below), and also
|
||||
at <http://fdutils.linux.lu/faq.html>.
|
||||
|
||||
|
||||
LILO configuration options (Thinkpad users, read this)
|
||||
======================================================
|
||||
|
||||
The floppy driver is configured using the 'floppy=' option in
|
||||
The floppy driver is configured using the 'floppy=' option in
|
||||
lilo. This option can be typed at the boot prompt, or entered in the
|
||||
lilo configuration file.
|
||||
|
||||
Example: If your kernel is called linux-2.6.9, type the following line
|
||||
at the lilo boot prompt (if you have a thinkpad):
|
||||
Example: If your kernel is called linux-2.6.9, type the following line
|
||||
at the lilo boot prompt (if you have a thinkpad)::
|
||||
|
||||
linux-2.6.9 floppy=thinkpad
|
||||
|
||||
You may also enter the following line in /etc/lilo.conf, in the description
|
||||
of linux-2.6.9:
|
||||
of linux-2.6.9::
|
||||
|
||||
append = "floppy=thinkpad"
|
||||
|
||||
Several floppy related options may be given, example:
|
||||
Several floppy related options may be given, example::
|
||||
|
||||
linux-2.6.9 floppy=daring floppy=two_fdc
|
||||
append = "floppy=daring floppy=two_fdc"
|
||||
|
||||
If you give options both in the lilo config file and on the boot
|
||||
If you give options both in the lilo config file and on the boot
|
||||
prompt, the option strings of both places are concatenated, the boot
|
||||
prompt options coming last. That's why there are also options to
|
||||
restore the default behavior.
|
||||
|
@ -38,21 +40,23 @@ restore the default behavior.
|
|||
Module configuration options
|
||||
============================
|
||||
|
||||
If you use the floppy driver as a module, use the following syntax:
|
||||
modprobe floppy floppy="<options>"
|
||||
If you use the floppy driver as a module, use the following syntax::
|
||||
|
||||
Example:
|
||||
modprobe floppy floppy="omnibook messages"
|
||||
modprobe floppy floppy="<options>"
|
||||
|
||||
If you need certain options enabled every time you load the floppy driver,
|
||||
you can put:
|
||||
Example::
|
||||
|
||||
options floppy floppy="omnibook messages"
|
||||
modprobe floppy floppy="omnibook messages"
|
||||
|
||||
If you need certain options enabled every time you load the floppy driver,
|
||||
you can put::
|
||||
|
||||
options floppy floppy="omnibook messages"
|
||||
|
||||
in a configuration file in /etc/modprobe.d/.
|
||||
|
||||
|
||||
The floppy driver related options are:
|
||||
The floppy driver related options are:
|
||||
|
||||
floppy=asus_pci
|
||||
Sets the bit mask to allow only units 0 and 1. (default)
|
||||
|
@ -70,8 +74,7 @@ in a configuration file in /etc/modprobe.d/.
|
|||
Tells the floppy driver that you have only one floppy controller.
|
||||
(default)
|
||||
|
||||
floppy=two_fdc
|
||||
floppy=<address>,two_fdc
|
||||
floppy=two_fdc / floppy=<address>,two_fdc
|
||||
Tells the floppy driver that you have two floppy controllers.
|
||||
The second floppy controller is assumed to be at <address>.
|
||||
This option is not needed if the second controller is at address
|
||||
|
@ -84,8 +87,7 @@ in a configuration file in /etc/modprobe.d/.
|
|||
floppy=0,thinkpad
|
||||
Tells the floppy driver that you don't have a Thinkpad.
|
||||
|
||||
floppy=omnibook
|
||||
floppy=nodma
|
||||
floppy=omnibook / floppy=nodma
|
||||
Tells the floppy driver not to use Dma for data transfers.
|
||||
This is needed on HP Omnibooks, which don't have a workable
|
||||
DMA channel for the floppy driver. This option is also useful
|
||||
|
@ -144,14 +146,16 @@ in a configuration file in /etc/modprobe.d/.
|
|||
described in the physical CMOS), or if your BIOS uses
|
||||
non-standard CMOS types. The CMOS types are:
|
||||
|
||||
0 - Use the value of the physical CMOS
|
||||
1 - 5 1/4 DD
|
||||
2 - 5 1/4 HD
|
||||
3 - 3 1/2 DD
|
||||
4 - 3 1/2 HD
|
||||
5 - 3 1/2 ED
|
||||
6 - 3 1/2 ED
|
||||
16 - unknown or not installed
|
||||
== ==================================
|
||||
0 Use the value of the physical CMOS
|
||||
1 5 1/4 DD
|
||||
2 5 1/4 HD
|
||||
3 3 1/2 DD
|
||||
4 3 1/2 HD
|
||||
5 3 1/2 ED
|
||||
6 3 1/2 ED
|
||||
16 unknown or not installed
|
||||
== ==================================
|
||||
|
||||
(Note: there are two valid types for ED drives. This is because 5 was
|
||||
initially chosen to represent floppy *tapes*, and 6 for ED drives.
|
||||
|
@ -162,8 +166,7 @@ in a configuration file in /etc/modprobe.d/.
|
|||
Print a warning message when an unexpected interrupt is received.
|
||||
(default)
|
||||
|
||||
floppy=no_unexpected_interrupts
|
||||
floppy=L40SX
|
||||
floppy=no_unexpected_interrupts / floppy=L40SX
|
||||
Don't print a message when an unexpected interrupt is received. This
|
||||
is needed on IBM L40SX laptops in certain video modes. (There seems
|
||||
to be an interaction between video and floppy. The unexpected
|
||||
|
@ -199,47 +202,54 @@ in a configuration file in /etc/modprobe.d/.
|
|||
Sets the floppy DMA channel to <nr> instead of 2.
|
||||
|
||||
floppy=slow
|
||||
Use PS/2 stepping rate:
|
||||
" PS/2 floppies have much slower step rates than regular floppies.
|
||||
Use PS/2 stepping rate::
|
||||
|
||||
PS/2 floppies have much slower step rates than regular floppies.
|
||||
It's been recommended that take about 1/4 of the default speed
|
||||
in some more extreme cases."
|
||||
in some more extreme cases.
|
||||
|
||||
|
||||
Supporting utilities and additional documentation:
|
||||
==================================================
|
||||
|
||||
Additional parameters of the floppy driver can be configured at
|
||||
Additional parameters of the floppy driver can be configured at
|
||||
runtime. Utilities which do this can be found in the fdutils package.
|
||||
This package also contains a new version of mtools which allows to
|
||||
access high capacity disks (up to 1992K on a high density 3 1/2 disk!).
|
||||
It also contains additional documentation about the floppy driver.
|
||||
|
||||
The latest version can be found at fdutils homepage:
|
||||
|
||||
http://fdutils.linux.lu
|
||||
|
||||
The fdutils releases can be found at:
|
||||
|
||||
http://fdutils.linux.lu/download.html
|
||||
|
||||
http://www.tux.org/pub/knaff/fdutils/
|
||||
|
||||
ftp://metalab.unc.edu/pub/Linux/utils/disk-management/
|
||||
|
||||
Reporting problems about the floppy driver
|
||||
==========================================
|
||||
|
||||
If you have a question or a bug report about the floppy driver, mail
|
||||
If you have a question or a bug report about the floppy driver, mail
|
||||
me at Alain.Knaff@poboxes.com . If you post to Usenet, preferably use
|
||||
comp.os.linux.hardware. As the volume in these groups is rather high,
|
||||
be sure to include the word "floppy" (or "FLOPPY") in the subject
|
||||
line. If the reported problem happens when mounting floppy disks, be
|
||||
sure to mention also the type of the filesystem in the subject line.
|
||||
|
||||
Be sure to read the FAQ before mailing/posting any bug reports!
|
||||
Be sure to read the FAQ before mailing/posting any bug reports!
|
||||
|
||||
Alain
|
||||
Alain
|
||||
|
||||
Changelog
|
||||
=========
|
||||
|
||||
10-30-2004 : Cleanup, updating, add reference to module configuration.
|
||||
10-30-2004 :
|
||||
Cleanup, updating, add reference to module configuration.
|
||||
James Nelson <james4765@gmail.com>
|
||||
|
||||
6-3-2000 : Original Document
|
||||
6-3-2000 :
|
||||
Original Document
|
|
@ -0,0 +1,16 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
===========================
|
||||
The Linux RapidIO Subsystem
|
||||
===========================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
floppy
|
||||
nbd
|
||||
paride
|
||||
ramdisk
|
||||
zram
|
||||
|
||||
drbd/index
|
|
@ -1,3 +1,4 @@
|
|||
==================================
|
||||
Network Block Device (TCP version)
|
||||
==================================
|
||||
|
||||
|
@ -28,4 +29,3 @@ max_part
|
|||
|
||||
nbds_max
|
||||
Number of block devices that should be initialized (default: 16).
|
||||
|
|
@ -1,15 +1,17 @@
|
|||
|
||||
Linux and parallel port IDE devices
|
||||
===================================
|
||||
Linux and parallel port IDE devices
|
||||
===================================
|
||||
|
||||
PARIDE v1.03 (c) 1997-8 Grant Guenther <grant@torque.net>
|
||||
|
||||
1. Introduction
|
||||
===============
|
||||
|
||||
Owing to the simplicity and near universality of the parallel port interface
|
||||
to personal computers, many external devices such as portable hard-disk,
|
||||
CD-ROM, LS-120 and tape drives use the parallel port to connect to their
|
||||
host computer. While some devices (notably scanners) use ad-hoc methods
|
||||
to pass commands and data through the parallel port interface, most
|
||||
to pass commands and data through the parallel port interface, most
|
||||
external devices are actually identical to an internal model, but with
|
||||
a parallel-port adapter chip added in. Some of the original parallel port
|
||||
adapters were little more than mechanisms for multiplexing a SCSI bus.
|
||||
|
@ -28,47 +30,50 @@ were to open up a parallel port CD-ROM drive, for instance, one would
|
|||
find a standard ATAPI CD-ROM drive, a power supply, and a single adapter
|
||||
that interconnected a standard PC parallel port cable and a standard
|
||||
IDE cable. It is usually possible to exchange the CD-ROM device with
|
||||
any other device using the IDE interface.
|
||||
any other device using the IDE interface.
|
||||
|
||||
The document describes the support in Linux for parallel port IDE
|
||||
devices. It does not cover parallel port SCSI devices, "ditto" tape
|
||||
drives or scanners. Many different devices are supported by the
|
||||
drives or scanners. Many different devices are supported by the
|
||||
parallel port IDE subsystem, including:
|
||||
|
||||
MicroSolutions backpack CD-ROM
|
||||
MicroSolutions backpack PD/CD
|
||||
MicroSolutions backpack hard-drives
|
||||
MicroSolutions backpack 8000t tape drive
|
||||
SyQuest EZ-135, EZ-230 & SparQ drives
|
||||
Avatar Shark
|
||||
Imation Superdisk LS-120
|
||||
Maxell Superdisk LS-120
|
||||
FreeCom Power CD
|
||||
Hewlett-Packard 5GB and 8GB tape drives
|
||||
Hewlett-Packard 7100 and 7200 CD-RW drives
|
||||
- MicroSolutions backpack CD-ROM
|
||||
- MicroSolutions backpack PD/CD
|
||||
- MicroSolutions backpack hard-drives
|
||||
- MicroSolutions backpack 8000t tape drive
|
||||
- SyQuest EZ-135, EZ-230 & SparQ drives
|
||||
- Avatar Shark
|
||||
- Imation Superdisk LS-120
|
||||
- Maxell Superdisk LS-120
|
||||
- FreeCom Power CD
|
||||
- Hewlett-Packard 5GB and 8GB tape drives
|
||||
- Hewlett-Packard 7100 and 7200 CD-RW drives
|
||||
|
||||
as well as most of the clone and no-name products on the market.
|
||||
|
||||
To support such a wide range of devices, PARIDE, the parallel port IDE
|
||||
subsystem, is actually structured in three parts. There is a base
|
||||
paride module which provides a registry and some common methods for
|
||||
accessing the parallel ports. The second component is a set of
|
||||
high-level drivers for each of the different types of supported devices:
|
||||
accessing the parallel ports. The second component is a set of
|
||||
high-level drivers for each of the different types of supported devices:
|
||||
|
||||
=== =============
|
||||
pd IDE disk
|
||||
pcd ATAPI CD-ROM
|
||||
pf ATAPI disk
|
||||
pt ATAPI tape
|
||||
pg ATAPI generic
|
||||
=== =============
|
||||
|
||||
(Currently, the pg driver is only used with CD-R drives).
|
||||
|
||||
The high-level drivers function according to the relevant standards.
|
||||
The third component of PARIDE is a set of low-level protocol drivers
|
||||
for each of the parallel port IDE adapter chips. Thanks to the interest
|
||||
and encouragement of Linux users from many parts of the world,
|
||||
and encouragement of Linux users from many parts of the world,
|
||||
support is available for almost all known adapter protocols:
|
||||
|
||||
==== ====================================== ====
|
||||
aten ATEN EH-100 (HK)
|
||||
bpck Microsolutions backpack (US)
|
||||
comm DataStor (old-type) "commuter" adapter (TW)
|
||||
|
@ -83,9 +88,11 @@ support is available for almost all known adapter protocols:
|
|||
ktti KT Technology PHd adapter (SG)
|
||||
on20 OnSpec 90c20 (US)
|
||||
on26 OnSpec 90c26 (US)
|
||||
==== ====================================== ====
|
||||
|
||||
|
||||
2. Using the PARIDE subsystem
|
||||
=============================
|
||||
|
||||
While configuring the Linux kernel, you may choose either to build
|
||||
the PARIDE drivers into your kernel, or to build them as modules.
|
||||
|
@ -94,10 +101,10 @@ In either case, you will need to select "Parallel port IDE device support"
|
|||
as well as at least one of the high-level drivers and at least one
|
||||
of the parallel port communication protocols. If you do not know
|
||||
what kind of parallel port adapter is used in your drive, you could
|
||||
begin by checking the file names and any text files on your DOS
|
||||
begin by checking the file names and any text files on your DOS
|
||||
installation floppy. Alternatively, you can look at the markings on
|
||||
the adapter chip itself. That's usually sufficient to identify the
|
||||
correct device.
|
||||
correct device.
|
||||
|
||||
You can actually select all the protocol modules, and allow the PARIDE
|
||||
subsystem to try them all for you.
|
||||
|
@ -105,8 +112,9 @@ subsystem to try them all for you.
|
|||
For the "brand-name" products listed above, here are the protocol
|
||||
and high-level drivers that you would use:
|
||||
|
||||
================ ============ ====== ========
|
||||
Manufacturer Model Driver Protocol
|
||||
|
||||
================ ============ ====== ========
|
||||
MicroSolutions CD-ROM pcd bpck
|
||||
MicroSolutions PD drive pf bpck
|
||||
MicroSolutions hard-drive pd bpck
|
||||
|
@ -119,8 +127,10 @@ and high-level drivers that you would use:
|
|||
Hewlett-Packard 5GB Tape pt epat
|
||||
Hewlett-Packard 7200e (CD) pcd epat
|
||||
Hewlett-Packard 7200e (CD-R) pg epat
|
||||
================ ============ ====== ========
|
||||
|
||||
2.1 Configuring built-in drivers
|
||||
---------------------------------
|
||||
|
||||
We recommend that you get to know how the drivers work and how to
|
||||
configure them as loadable modules, before attempting to compile a
|
||||
|
@ -143,7 +153,7 @@ protocol identification number and, for some devices, the drive's
|
|||
chain ID. While your system is booting, a number of messages are
|
||||
displayed on the console. Like all such messages, they can be
|
||||
reviewed with the 'dmesg' command. Among those messages will be
|
||||
some lines like:
|
||||
some lines like::
|
||||
|
||||
paride: bpck registered as protocol 0
|
||||
paride: epat registered as protocol 1
|
||||
|
@ -158,10 +168,10 @@ the last two digits of the drive's serial number (but read MicroSolutions'
|
|||
documentation about this).
|
||||
|
||||
As an example, let's assume that you have a MicroSolutions PD/CD drive
|
||||
with unit ID number 36 connected to the parallel port at 0x378, a SyQuest
|
||||
EZ-135 connected to the chained port on the PD/CD drive and also an
|
||||
Imation Superdisk connected to port 0x278. You could give the following
|
||||
options on your boot command:
|
||||
with unit ID number 36 connected to the parallel port at 0x378, a SyQuest
|
||||
EZ-135 connected to the chained port on the PD/CD drive and also an
|
||||
Imation Superdisk connected to port 0x278. You could give the following
|
||||
options on your boot command::
|
||||
|
||||
pd.drive0=0x378,1 pf.drive0=0x278,1 pf.drive1=0x378,0,36
|
||||
|
||||
|
@ -169,24 +179,27 @@ In the last option, pf.drive1 configures device /dev/pf1, the 0x378
|
|||
is the parallel port base address, the 0 is the protocol registration
|
||||
number and 36 is the chain ID.
|
||||
|
||||
Please note: while PARIDE will work both with and without the
|
||||
Please note: while PARIDE will work both with and without the
|
||||
PARPORT parallel port sharing system that is included by the
|
||||
"Parallel port support" option, PARPORT must be included and enabled
|
||||
if you want to use chains of devices on the same parallel port.
|
||||
|
||||
2.2 Loading and configuring PARIDE as modules
|
||||
----------------------------------------------
|
||||
|
||||
It is much faster and simpler to get to understand the PARIDE drivers
|
||||
if you use them as loadable kernel modules.
|
||||
if you use them as loadable kernel modules.
|
||||
|
||||
Note 1: using these drivers with the "kerneld" automatic module loading
|
||||
system is not recommended for beginners, and is not documented here.
|
||||
Note 1:
|
||||
using these drivers with the "kerneld" automatic module loading
|
||||
system is not recommended for beginners, and is not documented here.
|
||||
|
||||
Note 2: if you build PARPORT support as a loadable module, PARIDE must
|
||||
also be built as loadable modules, and PARPORT must be loaded before the
|
||||
PARIDE modules.
|
||||
Note 2:
|
||||
if you build PARPORT support as a loadable module, PARIDE must
|
||||
also be built as loadable modules, and PARPORT must be loaded before
|
||||
the PARIDE modules.
|
||||
|
||||
To use PARIDE, you must begin by
|
||||
To use PARIDE, you must begin by::
|
||||
|
||||
insmod paride
|
||||
|
||||
|
@ -195,8 +208,8 @@ among other tasks.
|
|||
|
||||
Then, load as many of the protocol modules as you think you might need.
|
||||
As you load each module, it will register the protocols that it supports,
|
||||
and print a log message to your kernel log file and your console. For
|
||||
example:
|
||||
and print a log message to your kernel log file and your console. For
|
||||
example::
|
||||
|
||||
# insmod epat
|
||||
paride: epat registered as protocol 0
|
||||
|
@ -205,22 +218,22 @@ example:
|
|||
paride: k971 registered as protocol 2
|
||||
|
||||
Finally, you can load high-level drivers for each kind of device that
|
||||
you have connected. By default, each driver will autoprobe for a single
|
||||
you have connected. By default, each driver will autoprobe for a single
|
||||
device, but you can support up to four similar devices by giving their
|
||||
individual co-ordinates when you load the driver.
|
||||
|
||||
For example, if you had two no-name CD-ROM drives both using the
|
||||
KingByte KBIC-951A adapter, one on port 0x378 and the other on 0x3bc
|
||||
you could give the following command:
|
||||
you could give the following command::
|
||||
|
||||
# insmod pcd drive0=0x378,1 drive1=0x3bc,1
|
||||
|
||||
For most adapters, giving a port address and protocol number is sufficient,
|
||||
but check the source files in linux/drivers/block/paride for more
|
||||
but check the source files in linux/drivers/block/paride for more
|
||||
information. (Hopefully someone will write some man pages one day !).
|
||||
|
||||
As another example, here's what happens when PARPORT is installed, and
|
||||
a SyQuest EZ-135 is attached to port 0x378:
|
||||
a SyQuest EZ-135 is attached to port 0x378::
|
||||
|
||||
# insmod paride
|
||||
paride: version 1.0 installed
|
||||
|
@ -237,46 +250,47 @@ Note that the last line is the output from the generic partition table
|
|||
scanner - in this case it reports that it has found a disk with one partition.
|
||||
|
||||
2.3 Using a PARIDE device
|
||||
--------------------------
|
||||
|
||||
Once the drivers have been loaded, you can access PARIDE devices in the
|
||||
same way as their traditional counterparts. You will probably need to
|
||||
create the device "special files". Here is a simple script that you can
|
||||
cut to a file and execute:
|
||||
cut to a file and execute::
|
||||
|
||||
#!/bin/bash
|
||||
#
|
||||
# mkd -- a script to create the device special files for the PARIDE subsystem
|
||||
#
|
||||
function mkdev {
|
||||
mknod $1 $2 $3 $4 ; chmod 0660 $1 ; chown root:disk $1
|
||||
}
|
||||
#
|
||||
function pd {
|
||||
D=$( printf \\$( printf "x%03x" $[ $1 + 97 ] ) )
|
||||
mkdev pd$D b 45 $[ $1 * 16 ]
|
||||
for P in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
|
||||
do mkdev pd$D$P b 45 $[ $1 * 16 + $P ]
|
||||
done
|
||||
}
|
||||
#
|
||||
cd /dev
|
||||
#
|
||||
for u in 0 1 2 3 ; do pd $u ; done
|
||||
for u in 0 1 2 3 ; do mkdev pcd$u b 46 $u ; done
|
||||
for u in 0 1 2 3 ; do mkdev pf$u b 47 $u ; done
|
||||
for u in 0 1 2 3 ; do mkdev pt$u c 96 $u ; done
|
||||
for u in 0 1 2 3 ; do mkdev npt$u c 96 $[ $u + 128 ] ; done
|
||||
for u in 0 1 2 3 ; do mkdev pg$u c 97 $u ; done
|
||||
#
|
||||
# end of mkd
|
||||
#!/bin/bash
|
||||
#
|
||||
# mkd -- a script to create the device special files for the PARIDE subsystem
|
||||
#
|
||||
function mkdev {
|
||||
mknod $1 $2 $3 $4 ; chmod 0660 $1 ; chown root:disk $1
|
||||
}
|
||||
#
|
||||
function pd {
|
||||
D=$( printf \\$( printf "x%03x" $[ $1 + 97 ] ) )
|
||||
mkdev pd$D b 45 $[ $1 * 16 ]
|
||||
for P in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
|
||||
do mkdev pd$D$P b 45 $[ $1 * 16 + $P ]
|
||||
done
|
||||
}
|
||||
#
|
||||
cd /dev
|
||||
#
|
||||
for u in 0 1 2 3 ; do pd $u ; done
|
||||
for u in 0 1 2 3 ; do mkdev pcd$u b 46 $u ; done
|
||||
for u in 0 1 2 3 ; do mkdev pf$u b 47 $u ; done
|
||||
for u in 0 1 2 3 ; do mkdev pt$u c 96 $u ; done
|
||||
for u in 0 1 2 3 ; do mkdev npt$u c 96 $[ $u + 128 ] ; done
|
||||
for u in 0 1 2 3 ; do mkdev pg$u c 97 $u ; done
|
||||
#
|
||||
# end of mkd
|
||||
|
||||
With the device files and drivers in place, you can access PARIDE devices
|
||||
like any other Linux device. For example, to mount a CD-ROM in pcd0, use:
|
||||
like any other Linux device. For example, to mount a CD-ROM in pcd0, use::
|
||||
|
||||
mount /dev/pcd0 /cdrom
|
||||
|
||||
If you have a fresh Avatar Shark cartridge, and the drive is pda, you
|
||||
might do something like:
|
||||
might do something like::
|
||||
|
||||
fdisk /dev/pda -- make a new partition table with
|
||||
partition 1 of type 83
|
||||
|
@ -289,41 +303,46 @@ might do something like:
|
|||
|
||||
Devices like the Imation superdisk work in the same way, except that
|
||||
they do not have a partition table. For example to make a 120MB
|
||||
floppy that you could share with a DOS system:
|
||||
floppy that you could share with a DOS system::
|
||||
|
||||
mkdosfs /dev/pf0
|
||||
mount /dev/pf0 /mnt
|
||||
|
||||
|
||||
2.4 The pf driver
|
||||
------------------
|
||||
|
||||
The pf driver is intended for use with parallel port ATAPI disk
|
||||
devices. The most common devices in this category are PD drives
|
||||
and LS-120 drives. Traditionally, media for these devices are not
|
||||
partitioned. Consequently, the pf driver does not support partitioned
|
||||
media. This may be changed in a future version of the driver.
|
||||
media. This may be changed in a future version of the driver.
|
||||
|
||||
2.5 Using the pt driver
|
||||
------------------------
|
||||
|
||||
The pt driver for parallel port ATAPI tape drives is a minimal driver.
|
||||
It does not yet support many of the standard tape ioctl operations.
|
||||
It does not yet support many of the standard tape ioctl operations.
|
||||
For best performance, a block size of 32KB should be used. You will
|
||||
probably want to set the parallel port delay to 0, if you can.
|
||||
|
||||
2.6 Using the pg driver
|
||||
------------------------
|
||||
|
||||
The pg driver can be used in conjunction with the cdrecord program
|
||||
to create CD-ROMs. Please get cdrecord version 1.6.1 or later
|
||||
from ftp://ftp.fokus.gmd.de/pub/unix/cdrecord/ . To record CD-R media
|
||||
your parallel port should ideally be set to EPP mode, and the "port delay"
|
||||
should be set to 0. With those settings it is possible to record at 2x
|
||||
from ftp://ftp.fokus.gmd.de/pub/unix/cdrecord/ . To record CD-R media
|
||||
your parallel port should ideally be set to EPP mode, and the "port delay"
|
||||
should be set to 0. With those settings it is possible to record at 2x
|
||||
speed without any buffer underruns. If you cannot get the driver to work
|
||||
in EPP mode, try to use "bidirectional" or "PS/2" mode and 1x speeds only.
|
||||
|
||||
|
||||
3. Troubleshooting
|
||||
==================
|
||||
|
||||
3.1 Use EPP mode if you can
|
||||
----------------------------
|
||||
|
||||
The most common problems that people report with the PARIDE drivers
|
||||
concern the parallel port CMOS settings. At this time, none of the
|
||||
|
@ -332,6 +351,7 @@ If you are able to do so, please set your parallel port into EPP mode
|
|||
using your CMOS setup procedure.
|
||||
|
||||
3.2 Check the port delay
|
||||
-------------------------
|
||||
|
||||
Some parallel ports cannot reliably transfer data at full speed. To
|
||||
offset the errors, the PARIDE protocol modules introduce a "port
|
||||
|
@ -347,23 +367,25 @@ read the comments at the beginning of the driver source files in
|
|||
linux/drivers/block/paride.
|
||||
|
||||
3.3 Some drives need a printer reset
|
||||
-------------------------------------
|
||||
|
||||
There appear to be a number of "noname" external drives on the market
|
||||
that do not always power up correctly. We have noticed this with some
|
||||
drives based on OnSpec and older Freecom adapters. In these rare cases,
|
||||
the adapter can often be reinitialised by issuing a "printer reset" on
|
||||
the parallel port. As the reset operation is potentially disruptive in
|
||||
multiple device environments, the PARIDE drivers will not do it
|
||||
automatically. You can however, force a printer reset by doing:
|
||||
the parallel port. As the reset operation is potentially disruptive in
|
||||
multiple device environments, the PARIDE drivers will not do it
|
||||
automatically. You can however, force a printer reset by doing::
|
||||
|
||||
insmod lp reset=1
|
||||
rmmod lp
|
||||
|
||||
If you have one of these marginal cases, you should probably build
|
||||
your paride drivers as modules, and arrange to do the printer reset
|
||||
before loading the PARIDE drivers.
|
||||
before loading the PARIDE drivers.
|
||||
|
||||
3.4 Use the verbose option and dmesg if you need help
|
||||
------------------------------------------------------
|
||||
|
||||
While a lot of testing has gone into these drivers to make them work
|
||||
as smoothly as possible, problems will arise. If you do have problems,
|
||||
|
@ -373,7 +395,7 @@ clues, then please make sure that only one drive is hooked to your system,
|
|||
and that either (a) PARPORT is enabled or (b) no other device driver
|
||||
is using your parallel port (check in /proc/ioports). Then, load the
|
||||
appropriate drivers (you can load several protocol modules if you want)
|
||||
as in:
|
||||
as in::
|
||||
|
||||
# insmod paride
|
||||
# insmod epat
|
||||
|
@ -394,12 +416,14 @@ by e-mail to grant@torque.net, or join the linux-parport mailing list
|
|||
and post your report there.
|
||||
|
||||
3.5 For more information or help
|
||||
---------------------------------
|
||||
|
||||
You can join the linux-parport mailing list by sending a mail message
|
||||
to
|
||||
to:
|
||||
|
||||
linux-parport-request@torque.net
|
||||
|
||||
with the single word
|
||||
with the single word::
|
||||
|
||||
subscribe
|
||||
|
||||
|
@ -412,6 +436,4 @@ have in your mail headers, when sending mail to the list server.
|
|||
You might also find some useful information on the linux-parport
|
||||
web pages (although they are not always up to date) at
|
||||
|
||||
http://web.archive.org/web/*/http://www.torque.net/parport/
|
||||
|
||||
|
||||
http://web.archive.org/web/%2E/http://www.torque.net/parport/
|
|
@ -1,7 +1,8 @@
|
|||
==========================================
|
||||
Using the RAM disk block device with Linux
|
||||
------------------------------------------
|
||||
==========================================
|
||||
|
||||
Contents:
|
||||
.. Contents:
|
||||
|
||||
1) Overview
|
||||
2) Kernel Command Line Parameters
|
||||
|
@ -42,7 +43,7 @@ rescue floppy disk.
|
|||
2a) Kernel Command Line Parameters
|
||||
|
||||
ramdisk_size=N
|
||||
==============
|
||||
Size of the ramdisk.
|
||||
|
||||
This parameter tells the RAM disk driver to set up RAM disks of N k size. The
|
||||
default is 4096 (4 MB).
|
||||
|
@ -50,16 +51,13 @@ default is 4096 (4 MB).
|
|||
2b) Module parameters
|
||||
|
||||
rd_nr
|
||||
=====
|
||||
/dev/ramX devices created.
|
||||
/dev/ramX devices created.
|
||||
|
||||
max_part
|
||||
========
|
||||
Maximum partition number.
|
||||
Maximum partition number.
|
||||
|
||||
rd_size
|
||||
=======
|
||||
See ramdisk_size.
|
||||
See ramdisk_size.
|
||||
|
||||
3) Using "rdev -r"
|
||||
------------------
|
||||
|
@ -71,11 +69,11 @@ to 2 MB (2^11) of where to find the RAM disk (this used to be the size). Bit
|
|||
prompt/wait sequence is to be given before trying to read the RAM disk. Since
|
||||
the RAM disk dynamically grows as data is being written into it, a size field
|
||||
is not required. Bits 11 to 13 are not currently used and may as well be zero.
|
||||
These numbers are no magical secrets, as seen below:
|
||||
These numbers are no magical secrets, as seen below::
|
||||
|
||||
./arch/x86/kernel/setup.c:#define RAMDISK_IMAGE_START_MASK 0x07FF
|
||||
./arch/x86/kernel/setup.c:#define RAMDISK_PROMPT_FLAG 0x8000
|
||||
./arch/x86/kernel/setup.c:#define RAMDISK_LOAD_FLAG 0x4000
|
||||
./arch/x86/kernel/setup.c:#define RAMDISK_IMAGE_START_MASK 0x07FF
|
||||
./arch/x86/kernel/setup.c:#define RAMDISK_PROMPT_FLAG 0x8000
|
||||
./arch/x86/kernel/setup.c:#define RAMDISK_LOAD_FLAG 0x4000
|
||||
|
||||
Consider a typical two floppy disk setup, where you will have the
|
||||
kernel on disk one, and have already put a RAM disk image onto disk #2.
|
||||
|
@ -92,20 +90,23 @@ sequence so that you have a chance to switch floppy disks.
|
|||
The command line equivalent is: "prompt_ramdisk=1"
|
||||
|
||||
Putting that together gives 2^15 + 2^14 + 0 = 49152 for an rdev word.
|
||||
So to create disk one of the set, you would do:
|
||||
So to create disk one of the set, you would do::
|
||||
|
||||
/usr/src/linux# cat arch/x86/boot/zImage > /dev/fd0
|
||||
/usr/src/linux# rdev /dev/fd0 /dev/fd0
|
||||
/usr/src/linux# rdev -r /dev/fd0 49152
|
||||
|
||||
If you make a boot disk that has LILO, then for the above, you would use:
|
||||
If you make a boot disk that has LILO, then for the above, you would use::
|
||||
|
||||
append = "ramdisk_start=0 load_ramdisk=1 prompt_ramdisk=1"
|
||||
Since the default start = 0 and the default prompt = 1, you could use:
|
||||
|
||||
Since the default start = 0 and the default prompt = 1, you could use::
|
||||
|
||||
append = "load_ramdisk=1"
|
||||
|
||||
|
||||
4) An Example of Creating a Compressed RAM Disk
|
||||
----------------------------------------------
|
||||
-----------------------------------------------
|
||||
|
||||
To create a RAM disk image, you will need a spare block device to
|
||||
construct it on. This can be the RAM disk device itself, or an
|
||||
|
@ -120,11 +121,11 @@ a) Decide on the RAM disk size that you want. Say 2 MB for this example.
|
|||
Create it by writing to the RAM disk device. (This step is not currently
|
||||
required, but may be in the future.) It is wise to zero out the
|
||||
area (esp. for disks) so that maximal compression is achieved for
|
||||
the unused blocks of the image that you are about to create.
|
||||
the unused blocks of the image that you are about to create::
|
||||
|
||||
dd if=/dev/zero of=/dev/ram0 bs=1k count=2048
|
||||
|
||||
b) Make a filesystem on it. Say ext2fs for this example.
|
||||
b) Make a filesystem on it. Say ext2fs for this example::
|
||||
|
||||
mke2fs -vm0 /dev/ram0 2048
|
||||
|
||||
|
@ -133,11 +134,11 @@ c) Mount it, copy the files you want to it (eg: /etc/* /dev/* ...)
|
|||
|
||||
d) Compress the contents of the RAM disk. The level of compression
|
||||
will be approximately 50% of the space used by the files. Unused
|
||||
space on the RAM disk will compress to almost nothing.
|
||||
space on the RAM disk will compress to almost nothing::
|
||||
|
||||
dd if=/dev/ram0 bs=1k count=2048 | gzip -v9 > /tmp/ram_image.gz
|
||||
|
||||
e) Put the kernel onto the floppy
|
||||
e) Put the kernel onto the floppy::
|
||||
|
||||
dd if=zImage of=/dev/fd0 bs=1k
|
||||
|
||||
|
@ -146,13 +147,13 @@ f) Put the RAM disk image onto the floppy, after the kernel. Use an offset
|
|||
(possibly larger) kernel onto the same floppy later without overlapping
|
||||
the RAM disk image. An offset of 400 kB for kernels about 350 kB in
|
||||
size would be reasonable. Make sure offset+size of ram_image.gz is
|
||||
not larger than the total space on your floppy (usually 1440 kB).
|
||||
not larger than the total space on your floppy (usually 1440 kB)::
|
||||
|
||||
dd if=/tmp/ram_image.gz of=/dev/fd0 bs=1k seek=400
|
||||
|
||||
g) Use "rdev" to set the boot device, RAM disk offset, prompt flag, etc.
|
||||
For prompt_ramdisk=1, load_ramdisk=1, ramdisk_start=400, one would
|
||||
have 2^15 + 2^14 + 400 = 49552.
|
||||
have 2^15 + 2^14 + 400 = 49552::
|
||||
|
||||
rdev /dev/fd0 /dev/fd0
|
||||
rdev -r /dev/fd0 49552
|
||||
|
@ -160,15 +161,17 @@ g) Use "rdev" to set the boot device, RAM disk offset, prompt flag, etc.
|
|||
That is it. You now have your boot/root compressed RAM disk floppy. Some
|
||||
users may wish to combine steps (d) and (f) by using a pipe.
|
||||
|
||||
--------------------------------------------------------------------------
|
||||
|
||||
Paul Gortmaker 12/95
|
||||
|
||||
Changelog:
|
||||
----------
|
||||
|
||||
10-22-04 : Updated to reflect changes in command line options, remove
|
||||
10-22-04 :
|
||||
Updated to reflect changes in command line options, remove
|
||||
obsolete references, general cleanup.
|
||||
James Nelson (james4765@gmail.com)
|
||||
|
||||
|
||||
12-95 : Original Document
|
||||
12-95 :
|
||||
Original Document
|
|
@ -1,7 +1,9 @@
|
|||
========================================
|
||||
zram: Compressed RAM based block devices
|
||||
----------------------------------------
|
||||
========================================
|
||||
|
||||
* Introduction
|
||||
Introduction
|
||||
============
|
||||
|
||||
The zram module creates RAM based block devices named /dev/zram<id>
|
||||
(<id> = 0, 1, ...). Pages written to these disks are compressed and stored
|
||||
|
@ -12,9 +14,11 @@ use as swap disks, various caches under /var and maybe many more :)
|
|||
Statistics for individual zram devices are exported through sysfs nodes at
|
||||
/sys/block/zram<id>/
|
||||
|
||||
* Usage
|
||||
Usage
|
||||
=====
|
||||
|
||||
There are several ways to configure and manage zram device(-s):
|
||||
|
||||
a) using zram and zram_control sysfs attributes
|
||||
b) using zramctl utility, provided by util-linux (util-linux@vger.kernel.org).
|
||||
|
||||
|
@ -22,7 +26,7 @@ In this document we will describe only 'manual' zram configuration steps,
|
|||
IOW, zram and zram_control sysfs attributes.
|
||||
|
||||
In order to get a better idea about zramctl please consult util-linux
|
||||
documentation, zramctl man-page or `zramctl --help'. Please be informed
|
||||
documentation, zramctl man-page or `zramctl --help`. Please be informed
|
||||
that zram maintainers do not develop/maintain util-linux or zramctl, should
|
||||
you have any questions please contact util-linux@vger.kernel.org
|
||||
|
||||
|
@ -30,19 +34,23 @@ Following shows a typical sequence of steps for using zram.
|
|||
|
||||
WARNING
|
||||
=======
|
||||
|
||||
For the sake of simplicity we skip error checking parts in most of the
|
||||
examples below. However, it is your sole responsibility to handle errors.
|
||||
|
||||
zram sysfs attributes always return negative values in case of errors.
|
||||
The list of possible return codes:
|
||||
-EBUSY -- an attempt to modify an attribute that cannot be changed once
|
||||
the device has been initialised. Please reset device first;
|
||||
-ENOMEM -- zram was not able to allocate enough memory to fulfil your
|
||||
needs;
|
||||
-EINVAL -- invalid input has been provided.
|
||||
|
||||
======== =============================================================
|
||||
-EBUSY an attempt to modify an attribute that cannot be changed once
|
||||
the device has been initialised. Please reset device first;
|
||||
-ENOMEM zram was not able to allocate enough memory to fulfil your
|
||||
needs;
|
||||
-EINVAL invalid input has been provided.
|
||||
======== =============================================================
|
||||
|
||||
If you use 'echo', the returned value that is changed by 'echo' utility,
|
||||
and, in general case, something like:
|
||||
and, in general case, something like::
|
||||
|
||||
echo 3 > /sys/block/zram0/max_comp_streams
|
||||
if [ $? -ne 0 ];
|
||||
|
@ -51,7 +59,11 @@ and, in general case, something like:
|
|||
|
||||
should suffice.
|
||||
|
||||
1) Load Module:
|
||||
1) Load Module
|
||||
==============
|
||||
|
||||
::
|
||||
|
||||
modprobe zram num_devices=4
|
||||
This creates 4 devices: /dev/zram{0,1,2,3}
|
||||
|
||||
|
@ -59,6 +71,8 @@ num_devices parameter is optional and tells zram how many devices should be
|
|||
pre-created. Default: 1.
|
||||
|
||||
2) Set max number of compression streams
|
||||
========================================
|
||||
|
||||
Regardless the value passed to this attribute, ZRAM will always
|
||||
allocate multiple compression streams - one per online CPUs - thus
|
||||
allowing several concurrent compression operations. The number of
|
||||
|
@ -66,16 +80,20 @@ allocated compression streams goes down when some of the CPUs
|
|||
become offline. There is no single-compression-stream mode anymore,
|
||||
unless you are running a UP system or has only 1 CPU online.
|
||||
|
||||
To find out how many streams are currently available:
|
||||
To find out how many streams are currently available::
|
||||
|
||||
cat /sys/block/zram0/max_comp_streams
|
||||
|
||||
3) Select compression algorithm
|
||||
===============================
|
||||
|
||||
Using comp_algorithm device attribute one can see available and
|
||||
currently selected (shown in square brackets) compression algorithms,
|
||||
change selected compression algorithm (once the device is initialised
|
||||
there is no way to change compression algorithm).
|
||||
|
||||
Examples:
|
||||
Examples::
|
||||
|
||||
#show supported compression algorithms
|
||||
cat /sys/block/zram0/comp_algorithm
|
||||
lzo [lz4]
|
||||
|
@ -83,20 +101,23 @@ Examples:
|
|||
#select lzo compression algorithm
|
||||
echo lzo > /sys/block/zram0/comp_algorithm
|
||||
|
||||
For the time being, the `comp_algorithm' content does not necessarily
|
||||
For the time being, the `comp_algorithm` content does not necessarily
|
||||
show every compression algorithm supported by the kernel. We keep this
|
||||
list primarily to simplify device configuration and one can configure
|
||||
a new device with a compression algorithm that is not listed in
|
||||
`comp_algorithm'. The thing is that, internally, ZRAM uses Crypto API
|
||||
`comp_algorithm`. The thing is that, internally, ZRAM uses Crypto API
|
||||
and, if some of the algorithms were built as modules, it's impossible
|
||||
to list all of them using, for instance, /proc/crypto or any other
|
||||
method. This, however, has an advantage of permitting the usage of
|
||||
custom crypto compression modules (implementing S/W or H/W compression).
|
||||
|
||||
4) Set Disksize
|
||||
===============
|
||||
|
||||
Set disk size by writing the value to sysfs node 'disksize'.
|
||||
The value can be either in bytes or you can use mem suffixes.
|
||||
Examples:
|
||||
Examples::
|
||||
|
||||
# Initialize /dev/zram0 with 50MB disksize
|
||||
echo $((50*1024*1024)) > /sys/block/zram0/disksize
|
||||
|
||||
|
@ -111,10 +132,13 @@ since we expect a 2:1 compression ratio. Note that zram uses about 0.1% of the
|
|||
size of the disk when not in use so a huge zram is wasteful.
|
||||
|
||||
5) Set memory limit: Optional
|
||||
=============================
|
||||
|
||||
Set memory limit by writing the value to sysfs node 'mem_limit'.
|
||||
The value can be either in bytes or you can use mem suffixes.
|
||||
In addition, you could change the value in runtime.
|
||||
Examples:
|
||||
Examples::
|
||||
|
||||
# limit /dev/zram0 with 50MB memory
|
||||
echo $((50*1024*1024)) > /sys/block/zram0/mem_limit
|
||||
|
||||
|
@ -126,7 +150,11 @@ Examples:
|
|||
# To disable memory limit
|
||||
echo 0 > /sys/block/zram0/mem_limit
|
||||
|
||||
6) Activate:
|
||||
6) Activate
|
||||
===========
|
||||
|
||||
::
|
||||
|
||||
mkswap /dev/zram0
|
||||
swapon /dev/zram0
|
||||
|
||||
|
@ -134,6 +162,7 @@ Examples:
|
|||
mount /dev/zram1 /tmp
|
||||
|
||||
7) Add/remove zram devices
|
||||
==========================
|
||||
|
||||
zram provides a control interface, which enables dynamic (on-demand) device
|
||||
addition and removal.
|
||||
|
@ -142,44 +171,51 @@ In order to add a new /dev/zramX device, perform read operation on hot_add
|
|||
attribute. This will return either new device's device id (meaning that you
|
||||
can use /dev/zram<id>) or error code.
|
||||
|
||||
Example:
|
||||
Example::
|
||||
|
||||
cat /sys/class/zram-control/hot_add
|
||||
1
|
||||
|
||||
To remove the existing /dev/zramX device (where X is a device id)
|
||||
execute
|
||||
execute::
|
||||
|
||||
echo X > /sys/class/zram-control/hot_remove
|
||||
|
||||
8) Stats:
|
||||
8) Stats
|
||||
========
|
||||
|
||||
Per-device statistics are exported as various nodes under /sys/block/zram<id>/
|
||||
|
||||
A brief description of exported device attributes. For more details please
|
||||
read Documentation/ABI/testing/sysfs-block-zram.
|
||||
|
||||
====================== ====== ===============================================
|
||||
Name access description
|
||||
---- ------ -----------
|
||||
====================== ====== ===============================================
|
||||
disksize RW show and set the device's disk size
|
||||
initstate RO shows the initialization state of the device
|
||||
reset WO trigger device reset
|
||||
mem_used_max WO reset the `mem_used_max' counter (see later)
|
||||
mem_limit WO specifies the maximum amount of memory ZRAM can use
|
||||
to store the compressed data
|
||||
writeback_limit WO specifies the maximum amount of write IO zram can
|
||||
write out to backing device as 4KB unit
|
||||
mem_used_max WO reset the `mem_used_max` counter (see later)
|
||||
mem_limit WO specifies the maximum amount of memory ZRAM can
|
||||
use to store the compressed data
|
||||
writeback_limit WO specifies the maximum amount of write IO zram
|
||||
can write out to backing device as 4KB unit
|
||||
writeback_limit_enable RW show and set writeback_limit feature
|
||||
max_comp_streams RW the number of possible concurrent compress operations
|
||||
max_comp_streams RW the number of possible concurrent compress
|
||||
operations
|
||||
comp_algorithm RW show and change the compression algorithm
|
||||
compact WO trigger memory compaction
|
||||
debug_stat RO this file is used for zram debugging purposes
|
||||
backing_dev RW set up backend storage for zram to write out
|
||||
idle WO mark allocated slot as idle
|
||||
====================== ====== ===============================================
|
||||
|
||||
|
||||
User space is advised to use the following files to read the device statistics.
|
||||
|
||||
File /sys/block/zram<id>/stat
|
||||
|
||||
Represents block layer statistics. Read Documentation/block/stat.txt for
|
||||
Represents block layer statistics. Read Documentation/block/stat.rst for
|
||||
details.
|
||||
|
||||
File /sys/block/zram<id>/io_stat
|
||||
|
@ -188,23 +224,31 @@ The stat file represents device's I/O statistics not accounted by block
|
|||
layer and, thus, not available in zram<id>/stat file. It consists of a
|
||||
single line of text and contains the following stats separated by
|
||||
whitespace:
|
||||
failed_reads the number of failed reads
|
||||
failed_writes the number of failed writes
|
||||
invalid_io the number of non-page-size-aligned I/O requests
|
||||
|
||||
============= =============================================================
|
||||
failed_reads The number of failed reads
|
||||
failed_writes The number of failed writes
|
||||
invalid_io The number of non-page-size-aligned I/O requests
|
||||
notify_free Depending on device usage scenario it may account
|
||||
|
||||
a) the number of pages freed because of swap slot free
|
||||
notifications or b) the number of pages freed because of
|
||||
REQ_OP_DISCARD requests sent by bio. The former ones are
|
||||
sent to a swap block device when a swap slot is freed,
|
||||
which implies that this disk is being used as a swap disk.
|
||||
notifications
|
||||
b) the number of pages freed because of
|
||||
REQ_OP_DISCARD requests sent by bio. The former ones are
|
||||
sent to a swap block device when a swap slot is freed,
|
||||
which implies that this disk is being used as a swap disk.
|
||||
|
||||
The latter ones are sent by filesystem mounted with
|
||||
discard option, whenever some data blocks are getting
|
||||
discarded.
|
||||
============= =============================================================
|
||||
|
||||
File /sys/block/zram<id>/mm_stat
|
||||
|
||||
The stat file represents device's mm statistics. It consists of a single
|
||||
line of text and contains the following stats separated by whitespace:
|
||||
|
||||
================ =============================================================
|
||||
orig_data_size uncompressed size of data stored in this disk.
|
||||
This excludes same-element-filled pages (same_pages) since
|
||||
no memory is allocated for them.
|
||||
|
@ -223,58 +267,71 @@ line of text and contains the following stats separated by whitespace:
|
|||
No memory is allocated for such pages.
|
||||
pages_compacted the number of pages freed during compaction
|
||||
huge_pages the number of incompressible pages
|
||||
================ =============================================================
|
||||
|
||||
File /sys/block/zram<id>/bd_stat
|
||||
|
||||
The stat file represents device's backing device statistics. It consists of
|
||||
a single line of text and contains the following stats separated by whitespace:
|
||||
|
||||
============== =============================================================
|
||||
bd_count size of data written in backing device.
|
||||
Unit: 4K bytes
|
||||
bd_reads the number of reads from backing device
|
||||
Unit: 4K bytes
|
||||
bd_writes the number of writes to backing device
|
||||
Unit: 4K bytes
|
||||
============== =============================================================
|
||||
|
||||
9) Deactivate
|
||||
=============
|
||||
|
||||
::
|
||||
|
||||
9) Deactivate:
|
||||
swapoff /dev/zram0
|
||||
umount /dev/zram1
|
||||
|
||||
10) Reset:
|
||||
Write any positive value to 'reset' sysfs node
|
||||
echo 1 > /sys/block/zram0/reset
|
||||
echo 1 > /sys/block/zram1/reset
|
||||
10) Reset
|
||||
=========
|
||||
|
||||
Write any positive value to 'reset' sysfs node::
|
||||
|
||||
echo 1 > /sys/block/zram0/reset
|
||||
echo 1 > /sys/block/zram1/reset
|
||||
|
||||
This frees all the memory allocated for the given device and
|
||||
resets the disksize to zero. You must set the disksize again
|
||||
before reusing the device.
|
||||
|
||||
* Optional Feature
|
||||
Optional Feature
|
||||
================
|
||||
|
||||
= writeback
|
||||
writeback
|
||||
---------
|
||||
|
||||
With CONFIG_ZRAM_WRITEBACK, zram can write idle/incompressible page
|
||||
to backing storage rather than keeping it in memory.
|
||||
To use the feature, admin should set up backing device via
|
||||
To use the feature, admin should set up backing device via::
|
||||
|
||||
"echo /dev/sda5 > /sys/block/zramX/backing_dev"
|
||||
echo /dev/sda5 > /sys/block/zramX/backing_dev
|
||||
|
||||
before disksize setting. It supports only partition at this moment.
|
||||
If admin want to use incompressible page writeback, they could do via
|
||||
If admin want to use incompressible page writeback, they could do via::
|
||||
|
||||
"echo huge > /sys/block/zramX/write"
|
||||
echo huge > /sys/block/zramX/write
|
||||
|
||||
To use idle page writeback, first, user need to declare zram pages
|
||||
as idle.
|
||||
as idle::
|
||||
|
||||
"echo all > /sys/block/zramX/idle"
|
||||
echo all > /sys/block/zramX/idle
|
||||
|
||||
From now on, any pages on zram are idle pages. The idle mark
|
||||
will be removed until someone request access of the block.
|
||||
IOW, unless there is access request, those pages are still idle pages.
|
||||
|
||||
Admin can request writeback of those idle pages at right timing via
|
||||
Admin can request writeback of those idle pages at right timing via::
|
||||
|
||||
"echo idle > /sys/block/zramX/writeback"
|
||||
echo idle > /sys/block/zramX/writeback
|
||||
|
||||
With the command, zram writeback idle pages from memory to the storage.
|
||||
|
||||
|
@ -285,7 +342,7 @@ to guarantee storage health for entire product life.
|
|||
To overcome the concern, zram supports "writeback_limit" feature.
|
||||
The "writeback_limit_enable"'s default value is 0 so that it doesn't limit
|
||||
any writeback. IOW, if admin want to apply writeback budget, he should
|
||||
enable writeback_limit_enable via
|
||||
enable writeback_limit_enable via::
|
||||
|
||||
$ echo 1 > /sys/block/zramX/writeback_limit_enable
|
||||
|
||||
|
@ -296,7 +353,7 @@ until admin set the budget via /sys/block/zramX/writeback_limit.
|
|||
assigned via /sys/block/zramX/writeback_limit is meaninless.)
|
||||
|
||||
If admin want to limit writeback as per-day 400M, he could do it
|
||||
like below.
|
||||
like below::
|
||||
|
||||
$ MB_SHIFT=20
|
||||
$ 4K_SHIFT=12
|
||||
|
@ -305,16 +362,16 @@ like below.
|
|||
$ echo 1 > /sys/block/zram0/writeback_limit_enable
|
||||
|
||||
If admin want to allow further write again once the bugdet is exausted,
|
||||
he could do it like below
|
||||
he could do it like below::
|
||||
|
||||
$ echo $((400<<MB_SHIFT>>4K_SHIFT)) > \
|
||||
/sys/block/zram0/writeback_limit
|
||||
|
||||
If admin want to see remaining writeback budget since he set,
|
||||
If admin want to see remaining writeback budget since he set::
|
||||
|
||||
$ cat /sys/block/zramX/writeback_limit
|
||||
|
||||
If admin want to disable writeback limit, he could do
|
||||
If admin want to disable writeback limit, he could do::
|
||||
|
||||
$ echo 0 > /sys/block/zramX/writeback_limit_enable
|
||||
|
||||
|
@ -326,25 +383,35 @@ budget in next setting is user's job.
|
|||
If admin want to measure writeback count in a certain period, he could
|
||||
know it via /sys/block/zram0/bd_stat's 3rd column.
|
||||
|
||||
= memory tracking
|
||||
memory tracking
|
||||
===============
|
||||
|
||||
With CONFIG_ZRAM_MEMORY_TRACKING, user can know information of the
|
||||
zram block. It could be useful to catch cold or incompressible
|
||||
pages of the process with*pagemap.
|
||||
|
||||
If you enable the feature, you could see block state via
|
||||
/sys/kernel/debug/zram/zram0/block_state". The output is as follows,
|
||||
/sys/kernel/debug/zram/zram0/block_state". The output is as follows::
|
||||
|
||||
300 75.033841 .wh.
|
||||
301 63.806904 s...
|
||||
302 63.806919 ..hi
|
||||
|
||||
First column is zram's block index.
|
||||
Second column is access time since the system was booted
|
||||
Third column is state of the block.
|
||||
(s: same page
|
||||
w: written page to backing store
|
||||
h: huge page
|
||||
i: idle page)
|
||||
First column
|
||||
zram's block index.
|
||||
Second column
|
||||
access time since the system was booted
|
||||
Third column
|
||||
state of the block:
|
||||
|
||||
s:
|
||||
same page
|
||||
w:
|
||||
written page to backing store
|
||||
h:
|
||||
huge page
|
||||
i:
|
||||
idle page
|
||||
|
||||
First line of above example says 300th block is accessed at 75.033841sec
|
||||
and the block's state is huge so it is written back to the backing
|
|
@ -90,9 +90,9 @@ the disk is not available then you have three options:
|
|||
run a null modem to a second machine and capture the output there
|
||||
using your favourite communication program. Minicom works well.
|
||||
|
||||
(3) Use Kdump (see Documentation/kdump/kdump.rst),
|
||||
(3) Use Kdump (see Documentation/admin-guide/kdump/kdump.rst),
|
||||
extract the kernel ring buffer from old memory with using dmesg
|
||||
gdbmacro in Documentation/kdump/gdbmacros.txt.
|
||||
gdbmacro in Documentation/admin-guide/kdump/gdbmacros.txt.
|
||||
|
||||
Finding the bug's location
|
||||
--------------------------
|
||||
|
|
|
@ -3,7 +3,7 @@ Control Groups
|
|||
==============
|
||||
|
||||
Written by Paul Menage <menage@google.com> based on
|
||||
Documentation/cgroup-v1/cpusets.rst
|
||||
Documentation/admin-guide/cgroup-v1/cpusets.rst
|
||||
|
||||
Original copyright statements from cpusets.txt:
|
||||
|
||||
|
@ -76,7 +76,7 @@ On their own, the only use for cgroups is for simple job
|
|||
tracking. The intention is that other subsystems hook into the generic
|
||||
cgroup support to provide new attributes for cgroups, such as
|
||||
accounting/limiting the resources which processes in a cgroup can
|
||||
access. For example, cpusets (see Documentation/cgroup-v1/cpusets.rst) allow
|
||||
access. For example, cpusets (see Documentation/admin-guide/cgroup-v1/cpusets.rst) allow
|
||||
you to associate a set of CPUs and a set of memory nodes with the
|
||||
tasks in each cgroup.
|
||||
|
|
@ -49,7 +49,7 @@ hooks, beyond what is already present, required to manage dynamic
|
|||
job placement on large systems.
|
||||
|
||||
Cpusets use the generic cgroup subsystem described in
|
||||
Documentation/cgroup-v1/cgroups.rst.
|
||||
Documentation/admin-guide/cgroup-v1/cgroups.rst.
|
||||
|
||||
Requests by a task, using the sched_setaffinity(2) system call to
|
||||
include CPUs in its CPU affinity mask, and using the mbind(2) and
|
|
@ -1,5 +1,3 @@
|
|||
:orphan:
|
||||
|
||||
========================
|
||||
Control Groups version 1
|
||||
========================
|
|
@ -10,7 +10,7 @@ Because VM is getting complex (one of reasons is memcg...), memcg's behavior
|
|||
is complex. This is a document for memcg's internal behavior.
|
||||
Please note that implementation details can be changed.
|
||||
|
||||
(*) Topics on API should be in Documentation/cgroup-v1/memory.rst)
|
||||
(*) Topics on API should be in Documentation/admin-guide/cgroup-v1/memory.rst)
|
||||
|
||||
0. How to record usage ?
|
||||
========================
|
||||
|
@ -327,7 +327,7 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
|
|||
You can see charges have been moved by reading ``*.usage_in_bytes`` or
|
||||
memory.stat of both A and B.
|
||||
|
||||
See 8.2 of Documentation/cgroup-v1/memory.rst to see what value should
|
||||
See 8.2 of Documentation/admin-guide/cgroup-v1/memory.rst to see what value should
|
||||
be written to move_charge_at_immigrate.
|
||||
|
||||
9.10 Memory thresholds
|
|
@ -9,7 +9,7 @@ This is the authoritative documentation on the design, interface and
|
|||
conventions of cgroup v2. It describes all userland-visible aspects
|
||||
of cgroup including core and specific controller behaviors. All
|
||||
future changes must be reflected in this document. Documentation for
|
||||
v1 is available under Documentation/cgroup-v1/.
|
||||
v1 is available under Documentation/admin-guide/cgroup-v1/.
|
||||
|
||||
.. CONTENTS
|
||||
|
||||
|
@ -1014,7 +1014,7 @@ All time durations are in microseconds.
|
|||
A read-only nested-key file which exists on non-root cgroups.
|
||||
|
||||
Shows pressure stall information for CPU. See
|
||||
Documentation/accounting/psi.txt for details.
|
||||
Documentation/accounting/psi.rst for details.
|
||||
|
||||
|
||||
Memory
|
||||
|
@ -1355,7 +1355,7 @@ PAGE_SIZE multiple when read back.
|
|||
A read-only nested-key file which exists on non-root cgroups.
|
||||
|
||||
Shows pressure stall information for memory. See
|
||||
Documentation/accounting/psi.txt for details.
|
||||
Documentation/accounting/psi.rst for details.
|
||||
|
||||
|
||||
Usage Guidelines
|
||||
|
@ -1498,7 +1498,7 @@ IO Interface Files
|
|||
A read-only nested-key file which exists on non-root cgroups.
|
||||
|
||||
Shows pressure stall information for IO. See
|
||||
Documentation/accounting/psi.txt for details.
|
||||
Documentation/accounting/psi.rst for details.
|
||||
|
||||
|
||||
Writeback
|
||||
|
|
|
@ -1,5 +1,3 @@
|
|||
:orphan:
|
||||
|
||||
=============
|
||||
Device Mapper
|
||||
=============
|
|
@ -13,7 +13,7 @@ the range specified.
|
|||
|
||||
The I/O statistics counters for each step-sized area of a region are
|
||||
in the same format as `/sys/block/*/stat` or `/proc/diskstats` (see:
|
||||
Documentation/iostats.txt). But two extra counters (12 and 13) are
|
||||
Documentation/admin-guide/iostats.rst). But two extra counters (12 and 13) are
|
||||
provided: total time spent reading and writing. When the histogram
|
||||
argument is used, the 14th parameter is reported that represents the
|
||||
histogram of latencies. All these counters may be accessed by sending
|
||||
|
@ -151,7 +151,7 @@ Messages
|
|||
The first 11 counters have the same meaning as
|
||||
`/sys/block/*/stat or /proc/diskstats`.
|
||||
|
||||
Please refer to Documentation/iostats.txt for details.
|
||||
Please refer to Documentation/admin-guide/iostats.rst for details.
|
||||
|
||||
1. the number of reads completed
|
||||
2. the number of reads merged
|
|
@ -1,4 +1,4 @@
|
|||
:orphan:
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
====
|
||||
gpio
|
|
@ -241,7 +241,7 @@ Guest mitigation mechanisms
|
|||
For further information about confining guests to a single or to a group
|
||||
of cores consult the cpusets documentation:
|
||||
|
||||
https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.rst
|
||||
https://www.kernel.org/doc/Documentation/admin-guide/cgroup-v1/cpusets.rst
|
||||
|
||||
.. _interrupt_isolation:
|
||||
|
||||
|
|
|
@ -16,6 +16,7 @@ etc.
|
|||
README
|
||||
kernel-parameters
|
||||
devices
|
||||
sysctl/index
|
||||
|
||||
This section describes CPU vulnerabilities and their mitigations.
|
||||
|
||||
|
@ -38,6 +39,8 @@ problems and bugs in particular.
|
|||
ramoops
|
||||
dynamic-debug-howto
|
||||
init
|
||||
kdump/index
|
||||
perf/index
|
||||
|
||||
This is the beginning of a section with information of interest to
|
||||
application developers. Documents covering various aspects of the kernel
|
||||
|
@ -56,11 +59,13 @@ configure specific aspects of kernel behavior to your liking.
|
|||
|
||||
initrd
|
||||
cgroup-v2
|
||||
cgroup-v1/index
|
||||
serial-console
|
||||
braille-console
|
||||
parport
|
||||
md
|
||||
module-signing
|
||||
rapidio
|
||||
sysrq
|
||||
unicode
|
||||
vga-softcursor
|
||||
|
@ -69,14 +74,37 @@ configure specific aspects of kernel behavior to your liking.
|
|||
java
|
||||
ras
|
||||
bcache
|
||||
blockdev/index
|
||||
ext4
|
||||
binderfs
|
||||
pm/index
|
||||
thunderbolt
|
||||
LSM/index
|
||||
mm/index
|
||||
namespaces/index
|
||||
perf-security
|
||||
acpi/index
|
||||
aoe/index
|
||||
btmrvl
|
||||
clearing-warn-once
|
||||
cpu-load
|
||||
cputopology
|
||||
device-mapper/index
|
||||
efi-stub
|
||||
gpio/index
|
||||
highuid
|
||||
hw_random
|
||||
iostats
|
||||
kernel-per-CPU-kthreads
|
||||
laptops/index
|
||||
lcd-panel-cgram
|
||||
ldm
|
||||
lockup-watchdogs
|
||||
numastat
|
||||
pnp
|
||||
rtc
|
||||
svga
|
||||
video-output
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue