## ia64/linux-2.6.18-xen.hg

### annotate Documentation/prio_tree.txt @ 854:950b9eb27661

find changesets by author, revision,
files, or words in the commit message

usbback: fix urb interval value for interrupt urbs.

Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>

Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>

author | Keir Fraser <keir.fraser@citrix.com> |
---|---|

date | Mon Apr 06 13:51:20 2009 +0100 (2009-04-06) |

parents | 831230e53067 |

children |

rev | line source |
---|---|

ian@0 | 1 The prio_tree.c code indexes vmas using 3 different indexes: |

ian@0 | 2 * heap_index = vm_pgoff + vm_size_in_pages : end_vm_pgoff |

ian@0 | 3 * radix_index = vm_pgoff : start_vm_pgoff |

ian@0 | 4 * size_index = vm_size_in_pages |

ian@0 | 5 |

ian@0 | 6 A regular radix-priority-search-tree indexes vmas using only heap_index and |

ian@0 | 7 radix_index. The conditions for indexing are: |

ian@0 | 8 * ->heap_index >= ->left->heap_index && |

ian@0 | 9 ->heap_index >= ->right->heap_index |

ian@0 | 10 * if (->heap_index == ->left->heap_index) |

ian@0 | 11 then ->radix_index < ->left->radix_index; |

ian@0 | 12 * if (->heap_index == ->right->heap_index) |

ian@0 | 13 then ->radix_index < ->right->radix_index; |

ian@0 | 14 * nodes are hashed to left or right subtree using radix_index |

ian@0 | 15 similar to a pure binary radix tree. |

ian@0 | 16 |

ian@0 | 17 A regular radix-priority-search-tree helps to store and query |

ian@0 | 18 intervals (vmas). However, a regular radix-priority-search-tree is only |

ian@0 | 19 suitable for storing vmas with different radix indices (vm_pgoff). |

ian@0 | 20 |

ian@0 | 21 Therefore, the prio_tree.c extends the regular radix-priority-search-tree |

ian@0 | 22 to handle many vmas with the same vm_pgoff. Such vmas are handled in |

ian@0 | 23 2 different ways: 1) All vmas with the same radix _and_ heap indices are |

ian@0 | 24 linked using vm_set.list, 2) if there are many vmas with the same radix |

ian@0 | 25 index, but different heap indices and if the regular radix-priority-search |

ian@0 | 26 tree cannot index them all, we build an overflow-sub-tree that indexes such |

ian@0 | 27 vmas using heap and size indices instead of heap and radix indices. For |

ian@0 | 28 example, in the figure below some vmas with vm_pgoff = 0 (zero) are |

ian@0 | 29 indexed by regular radix-priority-search-tree whereas others are pushed |

ian@0 | 30 into an overflow-subtree. Note that all vmas in an overflow-sub-tree have |

ian@0 | 31 the same vm_pgoff (radix_index) and if necessary we build different |

ian@0 | 32 overflow-sub-trees to handle each possible radix_index. For example, |

ian@0 | 33 in figure we have 3 overflow-sub-trees corresponding to radix indices |

ian@0 | 34 0, 2, and 4. |

ian@0 | 35 |

ian@0 | 36 In the final tree the first few (prio_tree_root->index_bits) levels |

ian@0 | 37 are indexed using heap and radix indices whereas the overflow-sub-trees below |

ian@0 | 38 those levels (i.e. levels prio_tree_root->index_bits + 1 and higher) are |

ian@0 | 39 indexed using heap and size indices. In overflow-sub-trees the size_index |

ian@0 | 40 is used for hashing the nodes to appropriate places. |

ian@0 | 41 |

ian@0 | 42 Now, an example prio_tree: |

ian@0 | 43 |

ian@0 | 44 vmas are represented [radix_index, size_index, heap_index] |

ian@0 | 45 i.e., [start_vm_pgoff, vm_size_in_pages, end_vm_pgoff] |

ian@0 | 46 |

ian@0 | 47 level prio_tree_root->index_bits = 3 |

ian@0 | 48 ----- |

ian@0 | 49 _ |

ian@0 | 50 0 [0,7,7] | |

ian@0 | 51 / \ | |

ian@0 | 52 ------------------ ------------ | Regular |

ian@0 | 53 / \ | radix priority |

ian@0 | 54 1 [1,6,7] [4,3,7] | search tree |

ian@0 | 55 / \ / \ | |

ian@0 | 56 ------- ----- ------ ----- | heap-and-radix |

ian@0 | 57 / \ / \ | indexed |

ian@0 | 58 2 [0,6,6] [2,5,7] [5,2,7] [6,1,7] | |

ian@0 | 59 / \ / \ / \ / \ | |

ian@0 | 60 3 [0,5,5] [1,5,6] [2,4,6] [3,4,7] [4,2,6] [5,1,6] [6,0,6] [7,0,7] | |

ian@0 | 61 / / / _ |

ian@0 | 62 / / / _ |

ian@0 | 63 4 [0,4,4] [2,3,5] [4,1,5] | |

ian@0 | 64 / / / | |

ian@0 | 65 5 [0,3,3] [2,2,4] [4,0,4] | Overflow-sub-trees |

ian@0 | 66 / / | |

ian@0 | 67 6 [0,2,2] [2,1,3] | heap-and-size |

ian@0 | 68 / / | indexed |

ian@0 | 69 7 [0,1,1] [2,0,2] | |

ian@0 | 70 / | |

ian@0 | 71 8 [0,0,0] | |

ian@0 | 72 _ |

ian@0 | 73 |

ian@0 | 74 Note that we use prio_tree_root->index_bits to optimize the height |

ian@0 | 75 of the heap-and-radix indexed tree. Since prio_tree_root->index_bits is |

ian@0 | 76 set according to the maximum end_vm_pgoff mapped, we are sure that all |

ian@0 | 77 bits (in vm_pgoff) above prio_tree_root->index_bits are 0 (zero). Therefore, |

ian@0 | 78 we only use the first prio_tree_root->index_bits as radix_index. |

ian@0 | 79 Whenever index_bits is increased in prio_tree_expand, we shuffle the tree |

ian@0 | 80 to make sure that the first prio_tree_root->index_bits levels of the tree |

ian@0 | 81 is indexed properly using heap and radix indices. |

ian@0 | 82 |

ian@0 | 83 We do not optimize the height of overflow-sub-trees using index_bits. |

ian@0 | 84 The reason is: there can be many such overflow-sub-trees and all of |

ian@0 | 85 them have to be suffled whenever the index_bits increases. This may involve |

ian@0 | 86 walking the whole prio_tree in prio_tree_insert->prio_tree_expand code |

ian@0 | 87 path which is not desirable. Hence, we do not optimize the height of the |

ian@0 | 88 heap-and-size indexed overflow-sub-trees using prio_tree->index_bits. |

ian@0 | 89 Instead the overflow sub-trees are indexed using full BITS_PER_LONG bits |

ian@0 | 90 of size_index. This may lead to skewed sub-trees because most of the |

ian@0 | 91 higher significant bits of the size_index are likely to be be 0 (zero). In |

ian@0 | 92 the example above, all 3 overflow-sub-trees are skewed. This may marginally |

ian@0 | 93 affect the performance. However, processes rarely map many vmas with the |

ian@0 | 94 same start_vm_pgoff but different end_vm_pgoffs. Therefore, we normally |

ian@0 | 95 do not require overflow-sub-trees to index all vmas. |

ian@0 | 96 |

ian@0 | 97 From the above discussion it is clear that the maximum height of |

ian@0 | 98 a prio_tree can be prio_tree_root->index_bits + BITS_PER_LONG. |

ian@0 | 99 However, in most of the common cases we do not need overflow-sub-trees, |

ian@0 | 100 so the tree height in the common cases will be prio_tree_root->index_bits. |

ian@0 | 101 |

ian@0 | 102 It is fair to mention here that the prio_tree_root->index_bits |

ian@0 | 103 is increased on demand, however, the index_bits is not decreased when |

ian@0 | 104 vmas are removed from the prio_tree. That's tricky to do. Hence, it's |

ian@0 | 105 left as a home work problem. |

ian@0 | 106 |

ian@0 | 107 |