1======================================== 2Generic Associative Array Implementation 3======================================== 4 5Overview 6======== 7 8This associative array implementation is an object container with the following 9properties: 10 111. Objects are opaque pointers. The implementation does not care where they 12 point (if anywhere) or what they point to (if anything). 13 14 .. note:: 15 16 Pointers to objects _must_ be zero in the least significant bit. 17 182. Objects do not need to contain linkage blocks for use by the array. This 19 permits an object to be located in multiple arrays simultaneously. 20 Rather, the array is made up of metadata blocks that point to objects. 21 223. Objects require index keys to locate them within the array. 23 244. Index keys must be unique. Inserting an object with the same key as one 25 already in the array will replace the old object. 26 275. Index keys can be of any length and can be of different lengths. 28 296. Index keys should encode the length early on, before any variation due to 30 length is seen. 31 327. Index keys can include a hash to scatter objects throughout the array. 33 348. The array can iterated over. The objects will not necessarily come out in 35 key order. 36 379. The array can be iterated over while it is being modified, provided the 38 RCU readlock is being held by the iterator. Note, however, under these 39 circumstances, some objects may be seen more than once. If this is a 40 problem, the iterator should lock against modification. Objects will not 41 be missed, however, unless deleted. 42 4310. Objects in the array can be looked up by means of their index key. 44 4511. Objects can be looked up while the array is being modified, provided the 46 RCU readlock is being held by the thread doing the look up. 47 48The implementation uses a tree of 16-pointer nodes internally that are indexed 49on each level by nibbles from the index key in the same manner as in a radix 50tree. To improve memory efficiency, shortcuts can be emplaced to skip over 51what would otherwise be a series of single-occupancy nodes. Further, nodes 52pack leaf object pointers into spare space in the node rather than making an 53extra branch until as such time an object needs to be added to a full node. 54 55 56The Public API 57============== 58 59The public API can be found in ``<linux/assoc_array.h>``. The associative 60array is rooted on the following structure:: 61 62 struct assoc_array { 63 ... 64 }; 65 66The code is selected by enabling ``CONFIG_ASSOCIATIVE_ARRAY`` with:: 67 68 ./script/config -e ASSOCIATIVE_ARRAY 69 70 71Edit Script 72----------- 73 74The insertion and deletion functions produce an 'edit script' that can later be 75applied to effect the changes without risking ``ENOMEM``. This retains the 76preallocated metadata blocks that will be installed in the internal tree and 77keeps track of the metadata blocks that will be removed from the tree when the 78script is applied. 79 80This is also used to keep track of dead blocks and dead objects after the 81script has been applied so that they can be freed later. The freeing is done 82after an RCU grace period has passed - thus allowing access functions to 83proceed under the RCU read lock. 84 85The script appears as outside of the API as a pointer of the type:: 86 87 struct assoc_array_edit; 88 89There are two functions for dealing with the script: 90 911. Apply an edit script:: 92 93 void assoc_array_apply_edit(struct assoc_array_edit *edit); 94 95 This will perform the edit functions, interpolating various write barriers 96 to permit accesses under the RCU read lock to continue. The edit script 97 will then be passed to ``call_rcu()`` to free it and any dead stuff it 98 points to. 99 1002. Cancel an edit script:: 101 102 void assoc_array_cancel_edit(struct assoc_array_edit *edit); 103 104 This frees the edit script and all preallocated memory immediately. If 105 this was for insertion, the new object is *not* released by this function, 106 but must rather be released by the caller. 107 108These functions are guaranteed not to fail. 109 110 111Operations Table 112---------------- 113 114Various functions take a table of operations:: 115 116 struct assoc_array_ops { 117 ... 118 }; 119 120This points to a number of methods, all of which need to be provided: 121 1221. Get a chunk of index key from caller data:: 123 124 unsigned long (*get_key_chunk)(const void *index_key, int level); 125 126 This should return a chunk of caller-supplied index key starting at the 127 *bit* position given by the level argument. The level argument will be a 128 multiple of ``ASSOC_ARRAY_KEY_CHUNK_SIZE`` and the function should return 129 ``ASSOC_ARRAY_KEY_CHUNK_SIZE bits``. No error is possible. 130 131 1322. Get a chunk of an object's index key:: 133 134 unsigned long (*get_object_key_chunk)(const void *object, int level); 135 136 As the previous function, but gets its data from an object in the array 137 rather than from a caller-supplied index key. 138 139 1403. See if this is the object we're looking for:: 141 142 bool (*compare_object)(const void *object, const void *index_key); 143 144 Compare the object against an index key and return ``true`` if it matches 145 and ``false`` if it doesn't. 146 147 1484. Diff the index keys of two objects:: 149 150 int (*diff_objects)(const void *object, const void *index_key); 151 152 Return the bit position at which the index key of the specified object 153 differs from the given index key or -1 if they are the same. 154 155 1565. Free an object:: 157 158 void (*free_object)(void *object); 159 160 Free the specified object. Note that this may be called an RCU grace period 161 after ``assoc_array_apply_edit()`` was called, so ``synchronize_rcu()`` may 162 be necessary on module unloading. 163 164 165Manipulation Functions 166---------------------- 167 168There are a number of functions for manipulating an associative array: 169 1701. Initialise an associative array:: 171 172 void assoc_array_init(struct assoc_array *array); 173 174 This initialises the base structure for an associative array. It can't fail. 175 176 1772. Insert/replace an object in an associative array:: 178 179 struct assoc_array_edit * 180 assoc_array_insert(struct assoc_array *array, 181 const struct assoc_array_ops *ops, 182 const void *index_key, 183 void *object); 184 185 This inserts the given object into the array. Note that the least 186 significant bit of the pointer must be zero as it's used to type-mark 187 pointers internally. 188 189 If an object already exists for that key then it will be replaced with the 190 new object and the old one will be freed automatically. 191 192 The ``index_key`` argument should hold index key information and is 193 passed to the methods in the ops table when they are called. 194 195 This function makes no alteration to the array itself, but rather returns 196 an edit script that must be applied. ``-ENOMEM`` is returned in the case of 197 an out-of-memory error. 198 199 The caller should lock exclusively against other modifiers of the array. 200 201 2023. Delete an object from an associative array:: 203 204 struct assoc_array_edit * 205 assoc_array_delete(struct assoc_array *array, 206 const struct assoc_array_ops *ops, 207 const void *index_key); 208 209 This deletes an object that matches the specified data from the array. 210 211 The ``index_key`` argument should hold index key information and is 212 passed to the methods in the ops table when they are called. 213 214 This function makes no alteration to the array itself, but rather returns 215 an edit script that must be applied. ``-ENOMEM`` is returned in the case of 216 an out-of-memory error. ``NULL`` will be returned if the specified object 217 is not found within the array. 218 219The caller should lock exclusively against other modifiers of the array. 220 221 2224. Delete all objects from an associative array:: 223 224 struct assoc_array_edit * 225 assoc_array_clear(struct assoc_array *array, 226 const struct assoc_array_ops *ops); 227 228 This deletes all the objects from an associative array and leaves it 229 completely empty. 230 231 This function makes no alteration to the array itself, but rather returns 232 an edit script that must be applied. ``-ENOMEM`` is returned in the case of 233 an out-of-memory error. 234 235 The caller should lock exclusively against other modifiers of the array. 236 237 2385. Destroy an associative array, deleting all objects:: 239 240 void assoc_array_destroy(struct assoc_array *array, 241 const struct assoc_array_ops *ops); 242 243 This destroys the contents of the associative array and leaves it 244 completely empty. It is not permitted for another thread to be traversing 245 the array under the RCU read lock at the same time as this function is 246 destroying it as no RCU deferral is performed on memory release - 247 something that would require memory to be allocated. 248 249 The caller should lock exclusively against other modifiers and accessors 250 of the array. 251 252 2536. Garbage collect an associative array:: 254 255 int assoc_array_gc(struct assoc_array *array, 256 const struct assoc_array_ops *ops, 257 bool (*iterator)(void *object, void *iterator_data), 258 void *iterator_data); 259 260 This iterates over the objects in an associative array and passes each one 261 to ``iterator()``. If ``iterator()`` returns ``true``, the object is kept. 262 If it returns ``false``, the object will be freed. If the ``iterator()`` 263 function returns ``true``, it must perform any appropriate refcount 264 incrementing on the object before returning. 265 266 The internal tree will be packed down if possible as part of the iteration 267 to reduce the number of nodes in it. 268 269 The ``iterator_data`` is passed directly to ``iterator()`` and is otherwise 270 ignored by the function. 271 272 The function will return ``0`` if successful and ``-ENOMEM`` if there wasn't 273 enough memory. 274 275 It is possible for other threads to iterate over or search the array under 276 the RCU read lock while this function is in progress. The caller should 277 lock exclusively against other modifiers of the array. 278 279 280Access Functions 281---------------- 282 283There are two functions for accessing an associative array: 284 2851. Iterate over all the objects in an associative array:: 286 287 int assoc_array_iterate(const struct assoc_array *array, 288 int (*iterator)(const void *object, 289 void *iterator_data), 290 void *iterator_data); 291 292 This passes each object in the array to the iterator callback function. 293 ``iterator_data`` is private data for that function. 294 295 This may be used on an array at the same time as the array is being 296 modified, provided the RCU read lock is held. Under such circumstances, 297 it is possible for the iteration function to see some objects twice. If 298 this is a problem, then modification should be locked against. The 299 iteration algorithm should not, however, miss any objects. 300 301 The function will return ``0`` if no objects were in the array or else it 302 will return the result of the last iterator function called. Iteration 303 stops immediately if any call to the iteration function results in a 304 non-zero return. 305 306 3072. Find an object in an associative array:: 308 309 void *assoc_array_find(const struct assoc_array *array, 310 const struct assoc_array_ops *ops, 311 const void *index_key); 312 313 This walks through the array's internal tree directly to the object 314 specified by the index key. 315 316 This may be used on an array at the same time as the array is being 317 modified, provided the RCU read lock is held. 318 319 The function will return the object if found (and set ``*_type`` to the 320 object type) or will return ``NULL`` if the object was not found. 321 322 323Index Key Form 324-------------- 325 326The index key can be of any form, but since the algorithms aren't told how long 327the key is, it is strongly recommended that the index key includes its length 328very early on before any variation due to the length would have an effect on 329comparisons. 330 331This will cause leaves with different length keys to scatter away from each 332other - and those with the same length keys to cluster together. 333 334It is also recommended that the index key begin with a hash of the rest of the 335key to maximise scattering throughout keyspace. 336 337The better the scattering, the wider and lower the internal tree will be. 338 339Poor scattering isn't too much of a problem as there are shortcuts and nodes 340can contain mixtures of leaves and metadata pointers. 341 342The index key is read in chunks of machine word. Each chunk is subdivided into 343one nibble (4 bits) per level, so on a 32-bit CPU this is good for 8 levels and 344on a 64-bit CPU, 16 levels. Unless the scattering is really poor, it is 345unlikely that more than one word of any particular index key will have to be 346used. 347 348 349Internal Workings 350================= 351 352The associative array data structure has an internal tree. This tree is 353constructed of two types of metadata blocks: nodes and shortcuts. 354 355A node is an array of slots. Each slot can contain one of four things: 356 357* A NULL pointer, indicating that the slot is empty. 358* A pointer to an object (a leaf). 359* A pointer to a node at the next level. 360* A pointer to a shortcut. 361 362 363Basic Internal Tree Layout 364-------------------------- 365 366Ignoring shortcuts for the moment, the nodes form a multilevel tree. The index 367key space is strictly subdivided by the nodes in the tree and nodes occur on 368fixed levels. For example:: 369 370 Level: 0 1 2 3 371 =============== =============== =============== =============== 372 NODE D 373 NODE B NODE C +------>+---+ 374 +------>+---+ +------>+---+ | | 0 | 375 NODE A | | 0 | | | 0 | | +---+ 376 +---+ | +---+ | +---+ | : : 377 | 0 | | : : | : : | +---+ 378 +---+ | +---+ | +---+ | | f | 379 | 1 |---+ | 3 |---+ | 7 |---+ +---+ 380 +---+ +---+ +---+ 381 : : : : | 8 |---+ 382 +---+ +---+ +---+ | NODE E 383 | e |---+ | f | : : +------>+---+ 384 +---+ | +---+ +---+ | 0 | 385 | f | | | f | +---+ 386 +---+ | +---+ : : 387 | NODE F +---+ 388 +------>+---+ | f | 389 | 0 | NODE G +---+ 390 +---+ +------>+---+ 391 : : | | 0 | 392 +---+ | +---+ 393 | 6 |---+ : : 394 +---+ +---+ 395 : : | f | 396 +---+ +---+ 397 | f | 398 +---+ 399 400In the above example, there are 7 nodes (A-G), each with 16 slots (0-f). 401Assuming no other meta data nodes in the tree, the key space is divided 402thusly: 403 404 =========== ==== 405 KEY PREFIX NODE 406 =========== ==== 407 137* D 408 138* E 409 13[0-69-f]* C 410 1[0-24-f]* B 411 e6* G 412 e[0-57-f]* F 413 [02-df]* A 414 =========== ==== 415 416So, for instance, keys with the following example index keys will be found in 417the appropriate nodes: 418 419 =============== ======= ==== 420 INDEX KEY PREFIX NODE 421 =============== ======= ==== 422 13694892892489 13 C 423 13795289025897 137 D 424 13889dde88793 138 E 425 138bbb89003093 138 E 426 1394879524789 12 C 427 1458952489 1 B 428 9431809de993ba \- A 429 b4542910809cd \- A 430 e5284310def98 e F 431 e68428974237 e6 G 432 e7fffcbd443 e F 433 f3842239082 \- A 434 =============== ======= ==== 435 436To save memory, if a node can hold all the leaves in its portion of keyspace, 437then the node will have all those leaves in it and will not have any metadata 438pointers - even if some of those leaves would like to be in the same slot. 439 440A node can contain a heterogeneous mix of leaves and metadata pointers. 441Metadata pointers must be in the slots that match their subdivisions of key 442space. The leaves can be in any slot not occupied by a metadata pointer. It 443is guaranteed that none of the leaves in a node will match a slot occupied by a 444metadata pointer. If the metadata pointer is there, any leaf whose key matches 445the metadata key prefix must be in the subtree that the metadata pointer points 446to. 447 448In the above example list of index keys, node A will contain: 449 450 ==== =============== ================== 451 SLOT CONTENT INDEX KEY (PREFIX) 452 ==== =============== ================== 453 1 PTR TO NODE B 1* 454 any LEAF 9431809de993ba 455 any LEAF b4542910809cd 456 e PTR TO NODE F e* 457 any LEAF f3842239082 458 ==== =============== ================== 459 460and node B: 461 462 ==== =============== ================== 463 SLOT CONTENT INDEX KEY (PREFIX) 464 ==== =============== ================== 465 3 PTR TO NODE C 13* 466 any LEAF 1458952489 467 ==== =============== ================== 468 469 470Shortcuts 471--------- 472 473Shortcuts are metadata records that jump over a piece of keyspace. A shortcut 474is a replacement for a series of single-occupancy nodes ascending through the 475levels. Shortcuts exist to save memory and to speed up traversal. 476 477It is possible for the root of the tree to be a shortcut - say, for example, 478the tree contains at least 17 nodes all with key prefix ``1111``. The 479insertion algorithm will insert a shortcut to skip over the ``1111`` keyspace 480in a single bound and get to the fourth level where these actually become 481different. 482 483 484Splitting And Collapsing Nodes 485------------------------------ 486 487Each node has a maximum capacity of 16 leaves and metadata pointers. If the 488insertion algorithm finds that it is trying to insert a 17th object into a 489node, that node will be split such that at least two leaves that have a common 490key segment at that level end up in a separate node rooted on that slot for 491that common key segment. 492 493If the leaves in a full node and the leaf that is being inserted are 494sufficiently similar, then a shortcut will be inserted into the tree. 495 496When the number of objects in the subtree rooted at a node falls to 16 or 497fewer, then the subtree will be collapsed down to a single node - and this will 498ripple towards the root if possible. 499 500 501Non-Recursive Iteration 502----------------------- 503 504Each node and shortcut contains a back pointer to its parent and the number of 505slot in that parent that points to it. None-recursive iteration uses these to 506proceed rootwards through the tree, going to the parent node, slot N + 1 to 507make sure progress is made without the need for a stack. 508 509The backpointers, however, make simultaneous alteration and iteration tricky. 510 511 512Simultaneous Alteration And Iteration 513------------------------------------- 514 515There are a number of cases to consider: 516 5171. Simple insert/replace. This involves simply replacing a NULL or old 518 matching leaf pointer with the pointer to the new leaf after a barrier. 519 The metadata blocks don't change otherwise. An old leaf won't be freed 520 until after the RCU grace period. 521 5222. Simple delete. This involves just clearing an old matching leaf. The 523 metadata blocks don't change otherwise. The old leaf won't be freed until 524 after the RCU grace period. 525 5263. Insertion replacing part of a subtree that we haven't yet entered. This 527 may involve replacement of part of that subtree - but that won't affect 528 the iteration as we won't have reached the pointer to it yet and the 529 ancestry blocks are not replaced (the layout of those does not change). 530 5314. Insertion replacing nodes that we're actively processing. This isn't a 532 problem as we've passed the anchoring pointer and won't switch onto the 533 new layout until we follow the back pointers - at which point we've 534 already examined the leaves in the replaced node (we iterate over all the 535 leaves in a node before following any of its metadata pointers). 536 537 We might, however, re-see some leaves that have been split out into a new 538 branch that's in a slot further along than we were at. 539 5405. Insertion replacing nodes that we're processing a dependent branch of. 541 This won't affect us until we follow the back pointers. Similar to (4). 542 5436. Deletion collapsing a branch under us. This doesn't affect us because the 544 back pointers will get us back to the parent of the new node before we 545 could see the new node. The entire collapsed subtree is thrown away 546 unchanged - and will still be rooted on the same slot, so we shouldn't 547 process it a second time as we'll go back to slot + 1. 548 549.. note:: 550 551 Under some circumstances, we need to simultaneously change the parent 552 pointer and the parent slot pointer on a node (say, for example, we 553 inserted another node before it and moved it up a level). We cannot do 554 this without locking against a read - so we have to replace that node too. 555 556 However, when we're changing a shortcut into a node this isn't a problem 557 as shortcuts only have one slot and so the parent slot number isn't used 558 when traversing backwards over one. This means that it's okay to change 559 the slot number first - provided suitable barriers are used to make sure 560 the parent slot number is read after the back pointer. 561 562Obsolete blocks and leaves are freed up after an RCU grace period has passed, 563so as long as anyone doing walking or iteration holds the RCU read lock, the 564old superstructure should not go away on them. 565