diff options
author | Linus Torvalds <torvalds@ppc970.osdl.org> | 2004-05-23 18:26:05 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2004-05-23 18:26:05 -0700 |
commit | 91d7f4e3a95e62455715a355b7be81175d2018ac (patch) | |
tree | 43bf76aa286c20a11a2458358f9eab400487816a /Documentation | |
parent | 3c65bcbbfdebee6372ad34771a8fc94d628d8408 (diff) | |
parent | be4284e3a038c6d4476cf841601658321fe4c764 (diff) | |
download | history-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.txt | 2 | ||||
-rwxr-xr-x | Documentation/BK-usage/gcapatch | 2 | ||||
-rw-r--r-- | Documentation/cachetlb.txt | 8 | ||||
-rw-r--r-- | Documentation/numastat.txt | 22 | ||||
-rw-r--r-- | Documentation/vm/locking | 2 |
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 |