aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@ppc970.osdl.org>2004-05-23 18:26:05 -0700
committerLinus Torvalds <torvalds@ppc970.osdl.org>2004-05-23 18:26:05 -0700
commit91d7f4e3a95e62455715a355b7be81175d2018ac (patch)
tree43bf76aa286c20a11a2458358f9eab400487816a /Documentation
parent3c65bcbbfdebee6372ad34771a8fc94d628d8408 (diff)
parentbe4284e3a038c6d4476cf841601658321fe4c764 (diff)
downloadhistory-91d7f4e3a95e62455715a355b7be81175d2018ac.tar.gz
Merge http://linux-sound.bkbits.net/linux-sound
into ppc970.osdl.org:/home/torvalds/v2.6/linux
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/BK-usage/bk-kernel-howto.txt2
-rwxr-xr-xDocumentation/BK-usage/gcapatch2
-rw-r--r--Documentation/cachetlb.txt8
-rw-r--r--Documentation/numastat.txt22
-rw-r--r--Documentation/vm/locking2
5 files changed, 29 insertions, 7 deletions
diff --git a/Documentation/BK-usage/bk-kernel-howto.txt b/Documentation/BK-usage/bk-kernel-howto.txt
index b7b9075d291083..8e10090355b121 100644
--- a/Documentation/BK-usage/bk-kernel-howto.txt
+++ b/Documentation/BK-usage/bk-kernel-howto.txt
@@ -279,5 +279,5 @@ specific state of the tree).
for my long-lived kernel branch?
A. Yes. This requires BK 3.x, though.
- bk export -tpatch -r`bk repogca bk://linux.bkbits.net/linux-2.5`,+
+ bk export -tpatch -r`bk repogca http://linux.bkbits.net/linux-2.5`,+
diff --git a/Documentation/BK-usage/gcapatch b/Documentation/BK-usage/gcapatch
index aaeb17dc7c7f29..9969906e8ad7bc 100755
--- a/Documentation/BK-usage/gcapatch
+++ b/Documentation/BK-usage/gcapatch
@@ -5,4 +5,4 @@
# Usage: gcapatch > foo.patch
#
-bk export -tpatch -hdu -r`bk repogca bk://linux.bkbits.net/linux-2.5`,+
+bk export -tpatch -hdu -r`bk repogca http://linux.bkbits.net/linux-2.5`,+
diff --git a/Documentation/cachetlb.txt b/Documentation/cachetlb.txt
index 094631ff54205c..98e4c6c7319d4a 100644
--- a/Documentation/cachetlb.txt
+++ b/Documentation/cachetlb.txt
@@ -322,10 +322,10 @@ maps this page at its virtual address.
about doing this.
The idea is, first at flush_dcache_page() time, if
- page->mapping->i_mmap{,_shared} are empty lists, just mark the
- architecture private page flag bit. Later, in
- update_mmu_cache(), a check is made of this flag bit, and if
- set the flush is done and the flag bit is cleared.
+ page->mapping->i_mmap is an empty tree and ->i_mmap_nonlinear
+ an empty list, just mark the architecture private page flag bit.
+ Later, in update_mmu_cache(), a check is made of this flag bit,
+ and if set the flush is done and the flag bit is cleared.
IMPORTANT NOTE: It is often important, if you defer the flush,
that the actual flush occurs on the same CPU
diff --git a/Documentation/numastat.txt b/Documentation/numastat.txt
new file mode 100644
index 00000000000000..80133ace1eb277
--- /dev/null
+++ b/Documentation/numastat.txt
@@ -0,0 +1,22 @@
+
+Numa policy hit/miss statistics
+
+/sys/devices/system/node/node*/numastat
+
+All units are pages. Hugepages have separate counters.
+
+numa_hit A process wanted to allocate memory from this node,
+ and succeeded.
+numa_miss A process wanted to allocate memory from this node,
+ but ended up with memory from another.
+numa_foreign A process wanted to allocate on another node,
+ but ended up with memory from this one.
+local_node A process ran on this node and got memory from it.
+other_node A process ran on this node and got memory from another node.
+interleave_hit Interleaving wanted to allocate from this node
+ and succeeded.
+
+For easier reading you can use the numastat utility from the numactl package
+(ftp://ftp.suse.com/pub/people/ak/numa/numactl*). Note that it only works
+well right now on machines with a small number of CPUs.
+
diff --git a/Documentation/vm/locking b/Documentation/vm/locking
index d29992e40aa28d..c3ef09ae3bb114 100644
--- a/Documentation/vm/locking
+++ b/Documentation/vm/locking
@@ -66,7 +66,7 @@ in some cases it is not really needed. Eg, vm_start is modified by
expand_stack(), it is hard to come up with a destructive scenario without
having the vmlist protection in this case.
-The page_table_lock nests with the inode i_shared_sem and the kmem cache
+The page_table_lock nests with the inode i_mmap_lock and the kmem cache
c_spinlock spinlocks. This is okay, since the kmem code asks for pages after
dropping c_spinlock. The page_table_lock also nests with pagecache_lock and
pagemap_lru_lock spinlocks, and no code asks for memory with these locks