You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge commit 'v3.6-rc5' into next
* commit 'v3.6-rc5': (1098 commits) Linux 3.6-rc5 HID: tpkbd: work even if the new Lenovo Keyboard driver is not configured Remove user-triggerable BUG from mpol_to_str xen/pciback: Fix proper FLR steps. uml: fix compile error in deliver_alarm() dj: memory scribble in logi_dj Fix order of arguments to compat_put_time[spec|val] xen: Use correct masking in xen_swiotlb_alloc_coherent. xen: fix logical error in tlb flushing xen/p2m: Fix one-off error in checking the P2M tree directory. powerpc: Don't use __put_user() in patch_instruction powerpc: Make sure IPI handlers see data written by IPI senders powerpc: Restore correct DSCR in context switch powerpc: Fix DSCR inheritance in copy_thread() powerpc: Keep thread.dscr and thread.dscr_inherit in sync powerpc: Update DSCR on all CPUs when writing sysfs dscr_default powerpc/powernv: Always go into nap mode when CPU is offline powerpc: Give hypervisor decrementer interrupts their own handler powerpc/vphn: Fix arch_update_cpu_topology() return value ARM: gemini: fix the gemini build ... Conflicts: drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c drivers/rapidio/devices/tsi721.c
This commit is contained in:
Bjorn Helgaas
@@ -210,3 +210,15 @@ Users:
|
||||
firmware assigned instance number of the PCI
|
||||
device that can help in understanding the firmware
|
||||
intended order of the PCI device.
|
||||
|
||||
What: /sys/bus/pci/devices/.../d3cold_allowed
|
||||
Date: July 2012
|
||||
Contact: Huang Ying <ying.huang@intel.com>
|
||||
Description:
|
||||
d3cold_allowed is bit to control whether the corresponding PCI
|
||||
device can be put into D3Cold state. If it is cleared, the
|
||||
device will never be put into D3Cold state. If it is set, the
|
||||
device may be put into D3Cold state if other requirements are
|
||||
satisfied too. Reading this attribute will show the current
|
||||
value of d3cold_allowed bit. Writing this attribute will set
|
||||
the value of d3cold_allowed bit.
|
||||
|
||||
@@ -5,4 +5,15 @@ Contact: "Ike Panhc <ike.pan@canonical.com>"
|
||||
Description:
|
||||
Control the power of camera module. 1 means on, 0 means off.
|
||||
|
||||
What: /sys/devices/platform/ideapad/fan_mode
|
||||
Date: June 2012
|
||||
KernelVersion: 3.6
|
||||
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
|
||||
Description:
|
||||
Change fan mode
|
||||
There are four available modes:
|
||||
* 0 -> Super Silent Mode
|
||||
* 1 -> Standard Mode
|
||||
* 2 -> Dust Cleaning
|
||||
* 4 -> Efficient Thermal Dissipation Mode
|
||||
|
||||
|
||||
@@ -224,8 +224,8 @@ all your transactions.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Then at umount time , in your put_super() (2.4) or write_super() (2.5)
|
||||
you can then call journal_destroy() to clean up your in-core journal object.
|
||||
Then at umount time , in your put_super() you can then call journal_destroy()
|
||||
to clean up your in-core journal object.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
||||
@@ -125,7 +125,7 @@ the structure refers to a radio tuner the
|
||||
<constant>V4L2_TUNER_CAP_NORM</constant> flags can't be used.</para>
|
||||
<para>If multiple frequency bands are supported, then
|
||||
<structfield>capability</structfield> is the union of all
|
||||
<structfield>capability></structfield> fields of each &v4l2-frequency-band;.
|
||||
<structfield>capability</structfield> fields of each &v4l2-frequency-band;.
|
||||
</para></entry>
|
||||
</row>
|
||||
<row>
|
||||
|
||||
@@ -3,15 +3,21 @@
|
||||
biodoc.txt
|
||||
- Notes on the Generic Block Layer Rewrite in Linux 2.5
|
||||
capability.txt
|
||||
- Generic Block Device Capability (/sys/block/<disk>/capability)
|
||||
- Generic Block Device Capability (/sys/block/<device>/capability)
|
||||
cfq-iosched.txt
|
||||
- CFQ IO scheduler tunables
|
||||
data-integrity.txt
|
||||
- Block data integrity
|
||||
deadline-iosched.txt
|
||||
- Deadline IO scheduler tunables
|
||||
ioprio.txt
|
||||
- Block io priorities (in CFQ scheduler)
|
||||
queue-sysfs.txt
|
||||
- Queue's sysfs entries
|
||||
request.txt
|
||||
- The members of struct request (in include/linux/blkdev.h)
|
||||
stat.txt
|
||||
- Block layer statistics in /sys/block/<dev>/stat
|
||||
- Block layer statistics in /sys/block/<device>/stat
|
||||
switching-sched.txt
|
||||
- Switching I/O schedulers at runtime
|
||||
writeback_cache_control.txt
|
||||
|
||||
@@ -1,3 +1,14 @@
|
||||
CFQ (Complete Fairness Queueing)
|
||||
===============================
|
||||
|
||||
The main aim of CFQ scheduler is to provide a fair allocation of the disk
|
||||
I/O bandwidth for all the processes which requests an I/O operation.
|
||||
|
||||
CFQ maintains the per process queue for the processes which request I/O
|
||||
operation(syncronous requests). In case of asynchronous requests, all the
|
||||
requests from all the processes are batched together according to their
|
||||
process's I/O priority.
|
||||
|
||||
CFQ ioscheduler tunables
|
||||
========================
|
||||
|
||||
@@ -25,6 +36,72 @@ there are multiple spindles behind single LUN (Host based hardware RAID
|
||||
controller or for storage arrays), setting slice_idle=0 might end up in better
|
||||
throughput and acceptable latencies.
|
||||
|
||||
back_seek_max
|
||||
-------------
|
||||
This specifies, given in Kbytes, the maximum "distance" for backward seeking.
|
||||
The distance is the amount of space from the current head location to the
|
||||
sectors that are backward in terms of distance.
|
||||
|
||||
This parameter allows the scheduler to anticipate requests in the "backward"
|
||||
direction and consider them as being the "next" if they are within this
|
||||
distance from the current head location.
|
||||
|
||||
back_seek_penalty
|
||||
-----------------
|
||||
This parameter is used to compute the cost of backward seeking. If the
|
||||
backward distance of request is just 1/back_seek_penalty from a "front"
|
||||
request, then the seeking cost of two requests is considered equivalent.
|
||||
|
||||
So scheduler will not bias toward one or the other request (otherwise scheduler
|
||||
will bias toward front request). Default value of back_seek_penalty is 2.
|
||||
|
||||
fifo_expire_async
|
||||
-----------------
|
||||
This parameter is used to set the timeout of asynchronous requests. Default
|
||||
value of this is 248ms.
|
||||
|
||||
fifo_expire_sync
|
||||
----------------
|
||||
This parameter is used to set the timeout of synchronous requests. Default
|
||||
value of this is 124ms. In case to favor synchronous requests over asynchronous
|
||||
one, this value should be decreased relative to fifo_expire_async.
|
||||
|
||||
slice_async
|
||||
-----------
|
||||
This parameter is same as of slice_sync but for asynchronous queue. The
|
||||
default value is 40ms.
|
||||
|
||||
slice_async_rq
|
||||
--------------
|
||||
This parameter is used to limit the dispatching of asynchronous request to
|
||||
device request queue in queue's slice time. The maximum number of request that
|
||||
are allowed to be dispatched also depends upon the io priority. Default value
|
||||
for this is 2.
|
||||
|
||||
slice_sync
|
||||
----------
|
||||
When a queue is selected for execution, the queues IO requests are only
|
||||
executed for a certain amount of time(time_slice) before switching to another
|
||||
queue. This parameter is used to calculate the time slice of synchronous
|
||||
queue.
|
||||
|
||||
time_slice is computed using the below equation:-
|
||||
time_slice = slice_sync + (slice_sync/5 * (4 - prio)). To increase the
|
||||
time_slice of synchronous queue, increase the value of slice_sync. Default
|
||||
value is 100ms.
|
||||
|
||||
quantum
|
||||
-------
|
||||
This specifies the number of request dispatched to the device queue. In a
|
||||
queue's time slice, a request will not be dispatched if the number of request
|
||||
in the device exceeds this parameter. This parameter is used for synchronous
|
||||
request.
|
||||
|
||||
In case of storage with several disk, this setting can limit the parallel
|
||||
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 IOPS Mode for group scheduling
|
||||
===================================
|
||||
Basic CFQ design is to provide priority based time slices. Higher priority
|
||||
|
||||
@@ -9,20 +9,71 @@ These files are the ones found in the /sys/block/xxx/queue/ directory.
|
||||
Files denoted with a RO postfix are readonly and the RW postfix means
|
||||
read-write.
|
||||
|
||||
add_random (RW)
|
||||
----------------
|
||||
This file allows to trun off the disk entropy contribution. Default
|
||||
value of this file is '1'(on).
|
||||
|
||||
discard_granularity (RO)
|
||||
-----------------------
|
||||
This shows the size of internal allocation of the device in bytes, if
|
||||
reported by the device. A value of '0' means device does not support
|
||||
the discard functionality.
|
||||
|
||||
discard_max_bytes (RO)
|
||||
----------------------
|
||||
Devices that support discard functionality may have internal limits on
|
||||
the number of bytes that can be trimmed or unmapped in a single operation.
|
||||
The discard_max_bytes parameter is set by the device driver to the maximum
|
||||
number of bytes that can be discarded in a single operation. Discard
|
||||
requests issued to the device must not exceed this limit. A discard_max_bytes
|
||||
value of 0 means that the device does not support discard functionality.
|
||||
|
||||
discard_zeroes_data (RO)
|
||||
------------------------
|
||||
When read, this file will show if the discarded block are zeroed by the
|
||||
device or not. If its value is '1' the blocks are zeroed otherwise not.
|
||||
|
||||
hw_sector_size (RO)
|
||||
-------------------
|
||||
This is the hardware sector size of the device, in bytes.
|
||||
|
||||
iostats (RW)
|
||||
-------------
|
||||
This file is used to control (on/off) the iostats accounting of the
|
||||
disk.
|
||||
|
||||
logical_block_size (RO)
|
||||
-----------------------
|
||||
This is the logcal block size of the device, in bytes.
|
||||
|
||||
max_hw_sectors_kb (RO)
|
||||
----------------------
|
||||
This is the maximum number of kilobytes supported in a single data transfer.
|
||||
|
||||
max_integrity_segments (RO)
|
||||
---------------------------
|
||||
When read, this file shows the max limit of integrity segments as
|
||||
set by block layer which a hardware controller can handle.
|
||||
|
||||
max_sectors_kb (RW)
|
||||
-------------------
|
||||
This is the maximum number of kilobytes that the block layer will allow
|
||||
for a filesystem request. Must be smaller than or equal to the maximum
|
||||
size allowed by the hardware.
|
||||
|
||||
max_segments (RO)
|
||||
-----------------
|
||||
Maximum number of segments of the device.
|
||||
|
||||
max_segment_size (RO)
|
||||
---------------------
|
||||
Maximum segment size of the device.
|
||||
|
||||
minimum_io_size (RO)
|
||||
--------------------
|
||||
This is the smallest preferred io size reported by the device.
|
||||
|
||||
nomerges (RW)
|
||||
-------------
|
||||
This enables the user to disable the lookup logic involved with IO
|
||||
@@ -45,11 +96,24 @@ per-block-cgroup request pool. IOW, if there are N block cgroups,
|
||||
each request queue may have upto N request pools, each independently
|
||||
regulated by nr_requests.
|
||||
|
||||
optimal_io_size (RO)
|
||||
--------------------
|
||||
This is the optimal io size reported by the device.
|
||||
|
||||
physical_block_size (RO)
|
||||
------------------------
|
||||
This is the physical block size of device, in bytes.
|
||||
|
||||
read_ahead_kb (RW)
|
||||
------------------
|
||||
Maximum number of kilobytes to read-ahead for filesystems on this block
|
||||
device.
|
||||
|
||||
rotational (RW)
|
||||
---------------
|
||||
This file is used to stat if the device is of rotational type or
|
||||
non-rotational type.
|
||||
|
||||
rq_affinity (RW)
|
||||
----------------
|
||||
If this option is '1', the block layer will migrate request completions to the
|
||||
|
||||
@@ -10,8 +10,8 @@ Required properties:
|
||||
- compatible : Should be "fsl,<chip>-esdhc"
|
||||
|
||||
Optional properties:
|
||||
- fsl,cd-internal : Indicate to use controller internal card detection
|
||||
- fsl,wp-internal : Indicate to use controller internal write protection
|
||||
- fsl,cd-controller : Indicate to use controller internal card detection
|
||||
- fsl,wp-controller : Indicate to use controller internal write protection
|
||||
|
||||
Examples:
|
||||
|
||||
@@ -19,8 +19,8 @@ esdhc@70004000 {
|
||||
compatible = "fsl,imx51-esdhc";
|
||||
reg = <0x70004000 0x4000>;
|
||||
interrupts = <1>;
|
||||
fsl,cd-internal;
|
||||
fsl,wp-internal;
|
||||
fsl,cd-controller;
|
||||
fsl,wp-controller;
|
||||
};
|
||||
|
||||
esdhc@70008000 {
|
||||
|
||||
@@ -9,9 +9,9 @@ Required properties:
|
||||
- regulators: list of regulators provided by this controller, must have
|
||||
property "regulator-compatible" to match their hardware counterparts:
|
||||
sm[0-2], ldo[0-9] and ldo_rtc
|
||||
- sm0-supply: The input supply for the SM0.
|
||||
- sm1-supply: The input supply for the SM1.
|
||||
- sm2-supply: The input supply for the SM2.
|
||||
- vin-sm0-supply: The input supply for the SM0.
|
||||
- vin-sm1-supply: The input supply for the SM1.
|
||||
- vin-sm2-supply: The input supply for the SM2.
|
||||
- vinldo01-supply: The input supply for the LDO1 and LDO2
|
||||
- vinldo23-supply: The input supply for the LDO2 and LDO3
|
||||
- vinldo4-supply: The input supply for the LDO4
|
||||
@@ -30,9 +30,9 @@ Example:
|
||||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
|
||||
sm0-supply = <&some_reg>;
|
||||
sm1-supply = <&some_reg>;
|
||||
sm2-supply = <&some_reg>;
|
||||
vin-sm0-supply = <&some_reg>;
|
||||
vin-sm1-supply = <&some_reg>;
|
||||
vin-sm2-supply = <&some_reg>;
|
||||
vinldo01-supply = <...>;
|
||||
vinldo23-supply = <...>;
|
||||
vinldo4-supply = <...>;
|
||||
|
||||
@@ -547,7 +547,7 @@ Why: KVM tracepoints provide mostly equivalent information in a much more
|
||||
----------------------------
|
||||
|
||||
What: at91-mci driver ("CONFIG_MMC_AT91")
|
||||
When: 3.7
|
||||
When: 3.8
|
||||
Why: There are two mci drivers: at91-mci and atmel-mci. The PDC support
|
||||
was added to atmel-mci as a first step to support more chips.
|
||||
Then at91-mci was kept only for old IP versions (on at91rm9200 and
|
||||
|
||||
@@ -114,7 +114,6 @@ prototypes:
|
||||
int (*drop_inode) (struct inode *);
|
||||
void (*evict_inode) (struct inode *);
|
||||
void (*put_super) (struct super_block *);
|
||||
void (*write_super) (struct super_block *);
|
||||
int (*sync_fs)(struct super_block *sb, int wait);
|
||||
int (*freeze_fs) (struct super_block *);
|
||||
int (*unfreeze_fs) (struct super_block *);
|
||||
@@ -136,7 +135,6 @@ write_inode:
|
||||
drop_inode: !!!inode->i_lock!!!
|
||||
evict_inode:
|
||||
put_super: write
|
||||
write_super: read
|
||||
sync_fs: read
|
||||
freeze_fs: write
|
||||
unfreeze_fs: write
|
||||
|
||||
@@ -94,9 +94,8 @@ protected.
|
||||
---
|
||||
[mandatory]
|
||||
|
||||
BKL is also moved from around sb operations. ->write_super() Is now called
|
||||
without BKL held. BKL should have been shifted into individual fs sb_op
|
||||
functions. If you don't need it, remove it.
|
||||
BKL is also moved from around sb operations. BKL should have been shifted into
|
||||
individual fs sb_op functions. If you don't need it, remove it.
|
||||
|
||||
---
|
||||
[informational]
|
||||
|
||||
@@ -137,6 +137,17 @@ errors=panic|continue|remount-ro
|
||||
without doing anything or remount the partition in
|
||||
read-only mode (default behavior).
|
||||
|
||||
discard -- If set, issues discard/TRIM commands to the block
|
||||
device when blocks are freed. This is useful for SSD devices
|
||||
and sparse/thinly-provisoned LUNs.
|
||||
|
||||
nfs -- This option maintains an index (cache) of directory
|
||||
inodes by i_logstart which is used by the nfs-related code to
|
||||
improve look-ups.
|
||||
|
||||
Enable this only if you want to export the FAT filesystem
|
||||
over NFS
|
||||
|
||||
<bool>: 0,1,yes,no,true,false
|
||||
|
||||
TODO
|
||||
|
||||
@@ -216,7 +216,6 @@ struct super_operations {
|
||||
void (*drop_inode) (struct inode *);
|
||||
void (*delete_inode) (struct inode *);
|
||||
void (*put_super) (struct super_block *);
|
||||
void (*write_super) (struct super_block *);
|
||||
int (*sync_fs)(struct super_block *sb, int wait);
|
||||
int (*freeze_fs) (struct super_block *);
|
||||
int (*unfreeze_fs) (struct super_block *);
|
||||
@@ -273,9 +272,6 @@ or bottom half).
|
||||
put_super: called when the VFS wishes to free the superblock
|
||||
(i.e. unmount). This is called with the superblock lock held
|
||||
|
||||
write_super: called when the VFS superblock needs to be written to
|
||||
disc. This method is optional
|
||||
|
||||
sync_fs: called when VFS is writing out all dirty data associated with
|
||||
a superblock. The second parameter indicates whether the method
|
||||
should wait until the write out has been completed. Optional.
|
||||
|
||||
@@ -262,9 +262,9 @@ MINIMUM_BATTERY_MINUTES=10
|
||||
|
||||
#
|
||||
# Allowed dirty background ratio, in percent. Once DIRTY_RATIO has been
|
||||
# exceeded, the kernel will wake pdflush which will then reduce the amount
|
||||
# of dirty memory to dirty_background_ratio. Set this nice and low, so once
|
||||
# some writeout has commenced, we do a lot of it.
|
||||
# exceeded, the kernel will wake flusher threads which will then reduce the
|
||||
# amount of dirty memory to dirty_background_ratio. Set this nice and low,
|
||||
# so once some writeout has commenced, we do a lot of it.
|
||||
#
|
||||
#DIRTY_BACKGROUND_RATIO=5
|
||||
|
||||
@@ -384,9 +384,9 @@ CPU_MAXFREQ=${CPU_MAXFREQ:-'slowest'}
|
||||
|
||||
#
|
||||
# Allowed dirty background ratio, in percent. Once DIRTY_RATIO has been
|
||||
# exceeded, the kernel will wake pdflush which will then reduce the amount
|
||||
# of dirty memory to dirty_background_ratio. Set this nice and low, so once
|
||||
# some writeout has commenced, we do a lot of it.
|
||||
# exceeded, the kernel will wake flusher threads which will then reduce the
|
||||
# amount of dirty memory to dirty_background_ratio. Set this nice and low,
|
||||
# so once some writeout has commenced, we do a lot of it.
|
||||
#
|
||||
DIRTY_BACKGROUND_RATIO=${DIRTY_BACKGROUND_RATIO:-'5'}
|
||||
|
||||
|
||||
@@ -51,8 +51,23 @@ Built-in netconsole starts immediately after the TCP stack is
|
||||
initialized and attempts to bring up the supplied dev at the supplied
|
||||
address.
|
||||
|
||||
The remote host can run either 'netcat -u -l -p <port>',
|
||||
'nc -l -u <port>' or syslogd.
|
||||
The remote host has several options to receive the kernel messages,
|
||||
for example:
|
||||
|
||||
1) syslogd
|
||||
|
||||
2) netcat
|
||||
|
||||
On distributions using a BSD-based netcat version (e.g. Fedora,
|
||||
openSUSE and Ubuntu) the listening port must be specified without
|
||||
the -p switch:
|
||||
|
||||
'nc -u -l -p <port>' / 'nc -u -l <port>' or
|
||||
'netcat -u -l -p <port>' / 'netcat -u -l <port>'
|
||||
|
||||
3) socat
|
||||
|
||||
'socat udp-recv:<port> -'
|
||||
|
||||
Dynamic reconfiguration:
|
||||
========================
|
||||
|
||||
@@ -840,9 +840,9 @@ static unsigned long i2c_pin_configs[] = {
|
||||
|
||||
static struct pinctrl_map __initdata mapping[] = {
|
||||
PIN_MAP_MUX_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", "i2c0"),
|
||||
PIN_MAP_MUX_CONFIGS_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", i2c_grp_configs),
|
||||
PIN_MAP_MUX_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0scl", i2c_pin_configs),
|
||||
PIN_MAP_MUX_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0sda", i2c_pin_configs),
|
||||
PIN_MAP_CONFIGS_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", i2c_grp_configs),
|
||||
PIN_MAP_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0scl", i2c_pin_configs),
|
||||
PIN_MAP_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0sda", i2c_pin_configs),
|
||||
};
|
||||
|
||||
Finally, some devices expect the mapping table to contain certain specific
|
||||
|
||||
@@ -46,14 +46,13 @@ restrictions, it can call prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, ...)
|
||||
so that any otherwise allowed process (even those in external pid namespaces)
|
||||
may attach.
|
||||
|
||||
These restrictions do not change how ptrace via PTRACE_TRACEME operates.
|
||||
|
||||
The sysctl settings are:
|
||||
The sysctl settings (writable only with CAP_SYS_PTRACE) are:
|
||||
|
||||
0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other
|
||||
process running under the same uid, as long as it is dumpable (i.e.
|
||||
did not transition uids, start privileged, or have called
|
||||
prctl(PR_SET_DUMPABLE...) already).
|
||||
prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
|
||||
unchanged.
|
||||
|
||||
1 - restricted ptrace: a process must have a predefined relationship
|
||||
with the inferior it wants to call PTRACE_ATTACH on. By default,
|
||||
@@ -61,12 +60,13 @@ The sysctl settings are:
|
||||
classic criteria is also met. To change the relationship, an
|
||||
inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare
|
||||
an allowed debugger PID to call PTRACE_ATTACH on the inferior.
|
||||
Using PTRACE_TRACEME is unchanged.
|
||||
|
||||
2 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace
|
||||
with PTRACE_ATTACH.
|
||||
with PTRACE_ATTACH, or through children calling PTRACE_TRACEME.
|
||||
|
||||
3 - no attach: no processes may use ptrace with PTRACE_ATTACH. Once set,
|
||||
this sysctl cannot be changed to a lower value.
|
||||
3 - no attach: no processes may use ptrace with PTRACE_ATTACH nor via
|
||||
PTRACE_TRACEME. Once set, this sysctl value cannot be changed.
|
||||
|
||||
The original children-only logic was based on the restrictions in grsecurity.
|
||||
|
||||
|
||||
@@ -76,8 +76,8 @@ huge pages although processes will also directly compact memory as required.
|
||||
|
||||
dirty_background_bytes
|
||||
|
||||
Contains the amount of dirty memory at which the pdflush background writeback
|
||||
daemon will start writeback.
|
||||
Contains the amount of dirty memory at which the background kernel
|
||||
flusher threads will start writeback.
|
||||
|
||||
Note: dirty_background_bytes is the counterpart of dirty_background_ratio. Only
|
||||
one of them may be specified at a time. When one sysctl is written it is
|
||||
@@ -89,7 +89,7 @@ other appears as 0 when read.
|
||||
dirty_background_ratio
|
||||
|
||||
Contains, as a percentage of total system memory, the number of pages at which
|
||||
the pdflush background writeback daemon will start writing out dirty data.
|
||||
the background kernel flusher threads will start writing out dirty data.
|
||||
|
||||
==============================================================
|
||||
|
||||
@@ -112,9 +112,9 @@ retained.
|
||||
dirty_expire_centisecs
|
||||
|
||||
This tunable is used to define when dirty data is old enough to be eligible
|
||||
for writeout by the pdflush daemons. It is expressed in 100'ths of a second.
|
||||
Data which has been dirty in-memory for longer than this interval will be
|
||||
written out next time a pdflush daemon wakes up.
|
||||
for writeout by the kernel flusher threads. It is expressed in 100'ths
|
||||
of a second. Data which has been dirty in-memory for longer than this
|
||||
interval will be written out next time a flusher thread wakes up.
|
||||
|
||||
==============================================================
|
||||
|
||||
@@ -128,7 +128,7 @@ data.
|
||||
|
||||
dirty_writeback_centisecs
|
||||
|
||||
The pdflush writeback daemons will periodically wake up and write `old' data
|
||||
The kernel flusher threads will periodically wake up and write `old' data
|
||||
out to disk. This tunable expresses the interval between those wakeups, in
|
||||
100'ths of a second.
|
||||
|
||||
|
||||
@@ -299,11 +299,17 @@ map_hugetlb.c.
|
||||
*******************************************************************
|
||||
|
||||
/*
|
||||
* hugepage-shm: see Documentation/vm/hugepage-shm.c
|
||||
* map_hugetlb: see tools/testing/selftests/vm/map_hugetlb.c
|
||||
*/
|
||||
|
||||
*******************************************************************
|
||||
|
||||
/*
|
||||
* hugepage-mmap: see Documentation/vm/hugepage-mmap.c
|
||||
* hugepage-shm: see tools/testing/selftests/vm/hugepage-shm.c
|
||||
*/
|
||||
|
||||
*******************************************************************
|
||||
|
||||
/*
|
||||
* hugepage-mmap: see tools/testing/selftests/vm/hugepage-mmap.c
|
||||
*/
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user