Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history 
yaml
---
r: 145583
b: refs/heads/master
c: cdc1cb0
h: refs/heads/master
i:
  145581: cdb8fc0
  145579: 6b73ef8
  145575: aa1bce0
  145567: f8fa893
v: v3
  • Loading branch information
Yinghai Lu authored and Ingo Molnar committed Apr 8, 2009
1 parent 08857f1 commit 3bd2342
Show file tree
Hide file tree
Showing 1,858 changed files with 46,918 additions and 50,415 deletions.
2 changes: 1 addition & 1 deletion [refs]
View file
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: 15e957d08dd4a841359cfec59ecb74041e0097aa
refs/heads/master: cdc1cb0d4445f39561a65204d26f89365f917550
1 change: 0 additions & 1 deletion trunk/.gitignore
View file
Original file line number Diff line number Diff line change
Expand Up @@ -49,7 +49,6 @@ include/linux/compile.h
include/linux/version.h
include/linux/utsrelease.h
include/linux/bounds.h
include/generated

# stgit generated dirs
patches-*
Expand Down
6 changes: 3 additions & 3 deletions trunk/Documentation/ABI/testing/debugfs-pktcdvd
View file
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
What: /sys/kernel/debug/pktcdvd/pktcdvd[0-7]
What: /debug/pktcdvd/pktcdvd[0-7]
Date: Oct. 2006
KernelVersion: 2.6.20
Contact: Thomas Maier <balagi@justmail.de>
Expand All @@ -10,10 +10,10 @@ debugfs interface
The pktcdvd module (packet writing driver) creates
these files in debugfs:

/sys/kernel/debug/pktcdvd/pktcdvd[0-7]/
/debug/pktcdvd/pktcdvd[0-7]/
info (0444) Lots of driver statistics and infos.

Example:
-------

cat /sys/kernel/debug/pktcdvd/pktcdvd0/info
cat /debug/pktcdvd/pktcdvd0/info
8 changes: 2 additions & 6 deletions trunk/Documentation/ABI/testing/sysfs-firmware-acpi
View file
Original file line number Diff line number Diff line change
Expand Up @@ -69,13 +69,9 @@ Description:
gpe1F: 0 invalid
gpe_all: 1192
sci: 1194
sci_not: 0

sci - The number of times the ACPI SCI
has been called and claimed an interrupt.

sci_not - The number of times the ACPI SCI
has been called and NOT claimed an interrupt.
sci - The total number of times the ACPI SCI
has claimed an interrupt.

gpe_all - count of SCI caused by GPEs.

Expand Down
11 changes: 3 additions & 8 deletions trunk/Documentation/DocBook/Makefile
View file
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@ PS_METHOD = $(prefer-db2x)

###
# The targets that may be used.
PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs
PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs

BOOKS := $(addprefix $(obj)/,$(DOCBOOKS))
xmldocs: $(BOOKS)
Expand Down Expand Up @@ -213,12 +213,11 @@ silent_gen_xml = :
dochelp:
@echo ' Linux kernel internal documentation in different formats:'
@echo ' htmldocs - HTML'
@echo ' installmandocs - install man pages generated by mandocs'
@echo ' mandocs - man pages'
@echo ' pdfdocs - PDF'
@echo ' psdocs - Postscript'
@echo ' xmldocs - XML DocBook'
@echo ' mandocs - man pages'
@echo ' installmandocs - install man pages generated by mandocs'
@echo ' cleandocs - clean all generated DocBook files'

###
# Temporary files left by various tools
Expand All @@ -236,10 +235,6 @@ clean-files := $(DOCBOOKS) \

clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man

cleandocs:
$(Q)rm -f $(call objectify, $(clean-files))
$(Q)rm -rf $(call objectify, $(clean-dirs))

# Declare the contents of the .PHONY variable as phony. We keep that
# information in a variable se we can use it in if_changed and friends.

Expand Down
19 changes: 13 additions & 6 deletions trunk/Documentation/block/biodoc.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1040,21 +1040,23 @@ Front merges are handled by the binary trees in AS and deadline schedulers.
iii. Plugging the queue to batch requests in anticipation of opportunities for
merge/sort optimizations

This is just the same as in 2.4 so far, though per-device unplugging
support is anticipated for 2.5. Also with a priority-based i/o scheduler,
such decisions could be based on request priorities.

Plugging is an approach that the current i/o scheduling algorithm resorts to so
that it collects up enough requests in the queue to be able to take
advantage of the sorting/merging logic in the elevator. If the
queue is empty when a request comes in, then it plugs the request queue
(sort of like plugging the bath tub of a vessel to get fluid to build up)
(sort of like plugging the bottom of a vessel to get fluid to build up)
till it fills up with a few more requests, before starting to service
the requests. This provides an opportunity to merge/sort the requests before
passing them down to the device. There are various conditions when the queue is
unplugged (to open up the flow again), either through a scheduled task or
could be on demand. For example wait_on_buffer sets the unplugging going
through sync_buffer() running blk_run_address_space(mapping). Or the caller
can do it explicity through blk_unplug(bdev). So in the read case,
the queue gets explicitly unplugged as part of waiting for completion on that
buffer. For page driven IO, the address space ->sync_page() takes care of
doing the blk_run_address_space().
(by running tq_disk) so the read gets satisfied soon. So in the read case,
the queue gets explicitly unplugged as part of waiting for completion,
in fact all queues get unplugged as a side-effect.

Aside:
This is kind of controversial territory, as it's not clear if plugging is
Expand All @@ -1065,6 +1067,11 @@ Aside:
multi-page bios being queued in one shot, we may not need to wait to merge
a big request from the broken up pieces coming by.

Per-queue granularity unplugging (still a Todo) may help reduce some of the
concerns with just a single tq_disk flush approach. Something like
blk_kick_queue() to unplug a specific queue (right away ?)
or optionally, all queues, is in the plan.

4.4 I/O contexts
I/O contexts provide a dynamically allocated per process data area. They may
be used in I/O schedulers, and in the block layer (could be used for IO statis,
Expand Down
18 changes: 0 additions & 18 deletions trunk/Documentation/cgroups/cpuacct.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -30,21 +30,3 @@ The above steps create a new group g1 and move the current shell
process (bash) into it. CPU time consumed by this bash and its children
can be obtained from g1/cpuacct.usage and the same is accumulated in
/cgroups/cpuacct.usage also.

cpuacct.stat file lists a few statistics which further divide the
CPU time obtained by the cgroup into user and system times. Currently
the following statistics are supported:

user: Time spent by tasks of the cgroup in user mode.
system: Time spent by tasks of the cgroup in kernel mode.

user and system are in USER_HZ unit.

cpuacct controller uses percpu_counter interface to collect user and
system times. This has two side effects:

- It is theoretically possible to see wrong values for user and system times.
This is because percpu_counter_read() on 32bit systems isn't safe
against concurrent writes.
- It is possible to see slightly outdated values for user and system times
due to the batch processing nature of percpu_counter.
55 changes: 23 additions & 32 deletions trunk/Documentation/cgroups/memory.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6,14 +6,15 @@ used here with the memory controller that is used in hardware.

Salient features

a. Enable control of Anonymous, Page Cache (mapped and unmapped) and
Swap Cache memory pages.
a. Enable control of both RSS (mapped) and Page Cache (unmapped) pages
b. The infrastructure allows easy addition of other types of memory to control
c. Provides *zero overhead* for non memory controller users
d. Provides a double LRU: global memory pressure causes reclaim from the
global LRU; a cgroup on hitting a limit, reclaims from the per
cgroup LRU

NOTE: Swap Cache (unmapped) is not accounted now.

Benefits and Purpose of the memory controller

The memory controller isolates the memory behaviour of a group of tasks
Expand Down Expand Up @@ -289,44 +290,34 @@ will be charged as a new owner of it.
moved to the parent. If you want to avoid that, force_empty will be useful.

5.2 stat file

memory.stat file includes following statistics

cache - # of bytes of page cache memory.
rss - # of bytes of anonymous and swap cache memory.
pgpgin - # of pages paged in (equivalent to # of charging events).
pgpgout - # of pages paged out (equivalent to # of uncharging events).
active_anon - # of bytes of anonymous and swap cache memory on active
lru list.
inactive_anon - # of bytes of anonymous memory and swap cache memory on
inactive lru list.
active_file - # of bytes of file-backed memory on active lru list.
inactive_file - # of bytes of file-backed memory on inactive lru list.
unevictable - # of bytes of memory that cannot be reclaimed (mlocked etc).

The following additional stats are dependent on CONFIG_DEBUG_VM.

inactive_ratio - VM internal parameter. (see mm/page_alloc.c)
recent_rotated_anon - VM internal parameter. (see mm/vmscan.c)
recent_rotated_file - VM internal parameter. (see mm/vmscan.c)
recent_scanned_anon - VM internal parameter. (see mm/vmscan.c)
recent_scanned_file - VM internal parameter. (see mm/vmscan.c)

Memo:
memory.stat file includes following statistics (now)
cache - # of pages from page-cache and shmem.
rss - # of pages from anonymous memory.
pgpgin - # of event of charging
pgpgout - # of event of uncharging
active_anon - # of pages on active lru of anon, shmem.
inactive_anon - # of pages on active lru of anon, shmem
active_file - # of pages on active lru of file-cache
inactive_file - # of pages on inactive lru of file cache
unevictable - # of pages cannot be reclaimed.(mlocked etc)

Below is depend on CONFIG_DEBUG_VM.
inactive_ratio - VM internal parameter. (see mm/page_alloc.c)
recent_rotated_anon - VM internal parameter. (see mm/vmscan.c)
recent_rotated_file - VM internal parameter. (see mm/vmscan.c)
recent_scanned_anon - VM internal parameter. (see mm/vmscan.c)
recent_scanned_file - VM internal parameter. (see mm/vmscan.c)

Memo:
recent_rotated means recent frequency of lru rotation.
recent_scanned means recent # of scans to lru.
showing for better debug please see the code for meanings.

Note:
Only anonymous and swap cache memory is listed as part of 'rss' stat.
This should not be confused with the true 'resident set size' or the
amount of physical memory used by the cgroup. Per-cgroup rss
accounting is not done yet.

5.3 swappiness
Similar to /proc/sys/vm/swappiness, but affecting a hierarchy of groups only.

Following cgroups' swapiness can't be changed.
Following cgroup's swapiness can't be changed.
- root cgroup (uses /proc/sys/vm/swappiness).
- a cgroup which uses hierarchy and it has child cgroup.
- a cgroup which uses hierarchy and not the root of hierarchy.
Expand Down
27 changes: 6 additions & 21 deletions trunk/Documentation/cgroups/resource_counter.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -47,18 +47,13 @@ to work with it.

2. Basic accounting routines

a. void res_counter_init(struct res_counter *rc,
struct res_counter *rc_parent)
a. void res_counter_init(struct res_counter *rc)

Initializes the resource counter. As usual, should be the first
routine called for a new counter.

The struct res_counter *parent can be used to define a hierarchical
child -> parent relationship directly in the res_counter structure,
NULL can be used to define no relationship.

c. int res_counter_charge(struct res_counter *rc, unsigned long val,
struct res_counter **limit_fail_at)
b. int res_counter_charge[_locked]
(struct res_counter *rc, unsigned long val)

When a resource is about to be allocated it has to be accounted
with the appropriate resource counter (controller should determine
Expand All @@ -72,25 +67,15 @@ to work with it.
* if the charging is performed first, then it should be uncharged
on error path (if the one is called).

If the charging fails and a hierarchical dependency exists, the
limit_fail_at parameter is set to the particular res_counter element
where the charging failed.

d. int res_counter_charge_locked
(struct res_counter *rc, unsigned long val)

The same as res_counter_charge(), but it must not acquire/release the
res_counter->lock internally (it must be called with res_counter->lock
held).

e. void res_counter_uncharge[_locked]
c. void res_counter_uncharge[_locked]
(struct res_counter *rc, unsigned long val)

When a resource is released (freed) it should be de-accounted
from the resource counter it was accounted to. This is called
"uncharging".

The _locked routines imply that the res_counter->lock is taken.
The _locked routines imply that the res_counter->lock is taken.


2.1 Other accounting routines

Expand Down
59 changes: 0 additions & 59 deletions trunk/Documentation/driver-model/platform.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -169,62 +169,3 @@ three different ways to find such a match:
be probed later if another device registers. (Which is OK, since
this interface is only for use with non-hotpluggable devices.)


Early Platform Devices and Drivers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The early platform interfaces provide platform data to platform device
drivers early on during the system boot. The code is built on top of the
early_param() command line parsing and can be executed very early on.

Example: "earlyprintk" class early serial console in 6 steps

1. Registering early platform device data
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The architecture code registers platform device data using the function
early_platform_add_devices(). In the case of early serial console this
should be hardware configuration for the serial port. Devices registered
at this point will later on be matched against early platform drivers.

2. Parsing kernel command line
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The architecture code calls parse_early_param() to parse the kernel
command line. This will execute all matching early_param() callbacks.
User specified early platform devices will be registered at this point.
For the early serial console case the user can specify port on the
kernel command line as "earlyprintk=serial.0" where "earlyprintk" is
the class string, "serial" is the name of the platfrom driver and
0 is the platform device id. If the id is -1 then the dot and the
id can be omitted.

3. Installing early platform drivers belonging to a certain class
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The architecture code may optionally force registration of all early
platform drivers belonging to a certain class using the function
early_platform_driver_register_all(). User specified devices from
step 2 have priority over these. This step is omitted by the serial
driver example since the early serial driver code should be disabled
unless the user has specified port on the kernel command line.

4. Early platform driver registration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Compiled-in platform drivers making use of early_platform_init() are
automatically registered during step 2 or 3. The serial driver example
should use early_platform_init("earlyprintk", &platform_driver).

5. Probing of early platform drivers belonging to a certain class
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The architecture code calls early_platform_driver_probe() to match
registered early platform devices associated with a certain class with
registered early platform drivers. Matched devices will get probed().
This step can be executed at any point during the early boot. As soon
as possible may be good for the serial port case.

6. Inside the early platform driver probe()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The driver code needs to take special care during early boot, especially
when it comes to memory allocation and interrupt registration. The code
in the probe() function can use is_early_platform_device() to check if
it is called at early platform device or at the regular platform device
time. The early serial driver performs register_console() at this point.

For further information, see <linux/platform_device.h>.
9 changes: 0 additions & 9 deletions trunk/Documentation/feature-removal-schedule.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -428,12 +428,3 @@ Why: In 2.6.27, the semantics of /sys/bus/pci/slots was redefined to
After a reasonable transition period, we will remove the legacy
fakephp interface.
Who: Alex Chiang <achiang@hp.com>

---------------------------

What: i2c-voodoo3 driver
When: October 2009
Why: Superseded by tdfxfb. I2C/DDC support used to live in a separate
driver but this caused driver conflicts.
Who: Jean Delvare <khali@linux-fr.org>
Krzysztof Helt <krzysztof.h1@wp.pl>
8 changes: 4 additions & 4 deletions trunk/Documentation/filesystems/caching/cachefiles.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -407,7 +407,7 @@ A NOTE ON SECURITY
==================

CacheFiles makes use of the split security in the task_struct. It allocates
its own task_security structure, and redirects current->cred to point to it
its own task_security structure, and redirects current->act_as to point to it
when it acts on behalf of another process, in that process's context.

The reason it does this is that it calls vfs_mkdir() and suchlike rather than
Expand All @@ -429,9 +429,9 @@ This means it may lose signals or ptrace events for example, and affects what
the process looks like in /proc.

So CacheFiles makes use of a logical split in the security between the
objective security (task->real_cred) and the subjective security (task->cred).
The objective security holds the intrinsic security properties of a process and
is never overridden. This is what appears in /proc, and is what is used when a
objective security (task->sec) and the subjective security (task->act_as). The
objective security holds the intrinsic security properties of a process and is
never overridden. This is what appears in /proc, and is what is used when a
process is the target of an operation by some other process (SIGKILL for
example).

Expand Down
5 changes: 2 additions & 3 deletions trunk/Documentation/filesystems/pohmelfs/design_notes.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -56,10 +56,9 @@ workloads and can fully utilize the bandwidth to the servers when doing bulk
data transfers.

POHMELFS clients operate with a working set of servers and are capable of balancing read-only
operations (like lookups or directory listings) between them according to IO priorities.
operations (like lookups or directory listings) between them.
Administrators can add or remove servers from the set at run-time via special commands (described
in Documentation/pohmelfs/info.txt file). Writes are replicated to all servers, which are connected
with write permission turned on. IO priority and permissions can be changed in run-time.
in Documentation/pohmelfs/info.txt file). Writes are replicated to all servers.

POHMELFS is capable of full data channel encryption and/or strong crypto hashing.
One can select any kernel supported cipher, encryption mode, hash type and operation mode
Expand Down
Loading

0 comments on commit 3bd2342

Please sign in to comment.