About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / core-api / assoc_array.rst




Custom Search

Based on kernel version 4.16.1. Page generated on 2018-04-09 11:52 EST.

1	========================================
2	Generic Associative Array Implementation
3	========================================
4	
5	Overview
6	========
7	
8	This associative array implementation is an object container with the following
9	properties:
10	
11	1. 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	
18	2. 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	
22	3. Objects require index keys to locate them within the array.
23	
24	4. 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	
27	5. Index keys can be of any length and can be of different lengths.
28	
29	6. Index keys should encode the length early on, before any variation due to
30	   length is seen.
31	
32	7. Index keys can include a hash to scatter objects throughout the array.
33	
34	8. The array can iterated over.  The objects will not necessarily come out in
35	   key order.
36	
37	9. The array can be iterated over whilst 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	
43	10. Objects in the array can be looked up by means of their index key.
44	
45	11. Objects can be looked up whilst the array is being modified, provided the
46	    RCU readlock is being held by the thread doing the look up.
47	
48	The implementation uses a tree of 16-pointer nodes internally that are indexed
49	on each level by nibbles from the index key in the same manner as in a radix
50	tree.  To improve memory efficiency, shortcuts can be emplaced to skip over
51	what would otherwise be a series of single-occupancy nodes.  Further, nodes
52	pack leaf object pointers into spare space in the node rather than making an
53	extra branch until as such time an object needs to be added to a full node.
54	
55	
56	The Public API
57	==============
58	
59	The public API can be found in ``<linux/assoc_array.h>``.  The associative
60	array is rooted on the following structure::
61	
62	    struct assoc_array {
63	            ...
64	    };
65	
66	The code is selected by enabling ``CONFIG_ASSOCIATIVE_ARRAY`` with::
67	
68	    ./script/config -e ASSOCIATIVE_ARRAY
69	
70	
71	Edit Script
72	-----------
73	
74	The insertion and deletion functions produce an 'edit script' that can later be
75	applied to effect the changes without risking ``ENOMEM``. This retains the
76	preallocated metadata blocks that will be installed in the internal tree and
77	keeps track of the metadata blocks that will be removed from the tree when the
78	script is applied.
79	
80	This is also used to keep track of dead blocks and dead objects after the
81	script has been applied so that they can be freed later.  The freeing is done
82	after an RCU grace period has passed - thus allowing access functions to
83	proceed under the RCU read lock.
84	
85	The script appears as outside of the API as a pointer of the type::
86	
87	    struct assoc_array_edit;
88	
89	There are two functions for dealing with the script:
90	
91	1. 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 points
98	to.
99	
100	2. 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	
108	These functions are guaranteed not to fail.
109	
110	
111	Operations Table
112	----------------
113	
114	Various functions take a table of operations::
115	
116	    struct assoc_array_ops {
117	            ...
118	    };
119	
120	This points to a number of methods, all of which need to be provided:
121	
122	1. 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	
132	2. 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	
140	3. 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 and
145	``false`` if it doesn't.
146	
147	
148	4. 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	
156	5. 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 be
162	necessary on module unloading.
163	
164	
165	Manipulation Functions
166	----------------------
167	
168	There are a number of functions for manipulating an associative array:
169	
170	1. 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	
177	2. 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	
202	3. 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 is
217	not found within the array.
218	
219	The caller should lock exclusively against other modifiers of the array.
220	
221	
222	4. 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	
238	5. 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	
253	6. 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 to
261	``iterator()``.  If ``iterator()`` returns ``true``, the object is kept.  If it
262	returns ``false``, the object will be freed.  If the ``iterator()`` function
263	returns ``true``, it must perform any appropriate refcount incrementing on the
264	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 whilst this function is in progress.  The caller should
277	lock exclusively against other modifiers of the array.
278	
279	
280	Access Functions
281	----------------
282	
283	There are two functions for accessing an associative array:
284	
285	1. 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 will
302	return the result of the last iterator function called.  Iteration stops
303	immediately if any call to the iteration function results in a non-zero
304	return.
305	
306	
307	2. 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 object
320	type) or will return ``NULL`` if the object was not found.
321	
322	
323	Index Key Form
324	--------------
325	
326	The index key can be of any form, but since the algorithms aren't told how long
327	the key is, it is strongly recommended that the index key includes its length
328	very early on before any variation due to the length would have an effect on
329	comparisons.
330	
331	This will cause leaves with different length keys to scatter away from each
332	other - and those with the same length keys to cluster together.
333	
334	It is also recommended that the index key begin with a hash of the rest of the
335	key to maximise scattering throughout keyspace.
336	
337	The better the scattering, the wider and lower the internal tree will be.
338	
339	Poor scattering isn't too much of a problem as there are shortcuts and nodes
340	can contain mixtures of leaves and metadata pointers.
341	
342	The index key is read in chunks of machine word.  Each chunk is subdivided into
343	one nibble (4 bits) per level, so on a 32-bit CPU this is good for 8 levels and
344	on a 64-bit CPU, 16 levels.  Unless the scattering is really poor, it is
345	unlikely that more than one word of any particular index key will have to be
346	used.
347	
348	
349	Internal Workings
350	=================
351	
352	The associative array data structure has an internal tree.  This tree is
353	constructed of two types of metadata blocks: nodes and shortcuts.
354	
355	A 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	
363	Basic Internal Tree Layout
364	--------------------------
365	
366	Ignoring shortcuts for the moment, the nodes form a multilevel tree.  The index
367	key space is strictly subdivided by the nodes in the tree and nodes occur on
368	fixed 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	
400	In the above example, there are 7 nodes (A-G), each with 16 slots (0-f).
401	Assuming no other meta data nodes in the tree, the key space is divided
402	thusly::
403	
404	    KEY PREFIX      NODE
405	    ==========      ====
406	    137*            D
407	    138*            E
408	    13[0-69-f]*     C
409	    1[0-24-f]*      B
410	    e6*             G
411	    e[0-57-f]*      F
412	    [02-df]*        A
413	
414	So, for instance, keys with the following example index keys will be found in
415	the appropriate nodes::
416	
417	    INDEX KEY       PREFIX  NODE
418	    =============== ======= ====
419	    13694892892489  13      C
420	    13795289025897  137     D
421	    13889dde88793   138     E
422	    138bbb89003093  138     E
423	    1394879524789   12      C
424	    1458952489      1       B
425	    9431809de993ba  -       A
426	    b4542910809cd   -       A
427	    e5284310def98   e       F
428	    e68428974237    e6      G
429	    e7fffcbd443     e       F
430	    f3842239082     -       A
431	
432	To save memory, if a node can hold all the leaves in its portion of keyspace,
433	then the node will have all those leaves in it and will not have any metadata
434	pointers - even if some of those leaves would like to be in the same slot.
435	
436	A node can contain a heterogeneous mix of leaves and metadata pointers.
437	Metadata pointers must be in the slots that match their subdivisions of key
438	space.  The leaves can be in any slot not occupied by a metadata pointer.  It
439	is guaranteed that none of the leaves in a node will match a slot occupied by a
440	metadata pointer.  If the metadata pointer is there, any leaf whose key matches
441	the metadata key prefix must be in the subtree that the metadata pointer points
442	to.
443	
444	In the above example list of index keys, node A will contain::
445	
446	    SLOT    CONTENT         INDEX KEY (PREFIX)
447	    ====    =============== ==================
448	    1       PTR TO NODE B   1*
449	    any     LEAF            9431809de993ba
450	    any     LEAF            b4542910809cd
451	    e       PTR TO NODE F   e*
452	    any     LEAF            f3842239082
453	
454	and node B::
455	
456	    3	PTR TO NODE C	13*
457	    any	LEAF		1458952489
458	
459	
460	Shortcuts
461	---------
462	
463	Shortcuts are metadata records that jump over a piece of keyspace.  A shortcut
464	is a replacement for a series of single-occupancy nodes ascending through the
465	levels.  Shortcuts exist to save memory and to speed up traversal.
466	
467	It is possible for the root of the tree to be a shortcut - say, for example,
468	the tree contains at least 17 nodes all with key prefix ``1111``.  The
469	insertion algorithm will insert a shortcut to skip over the ``1111`` keyspace
470	in a single bound and get to the fourth level where these actually become
471	different.
472	
473	
474	Splitting And Collapsing Nodes
475	------------------------------
476	
477	Each node has a maximum capacity of 16 leaves and metadata pointers.  If the
478	insertion algorithm finds that it is trying to insert a 17th object into a
479	node, that node will be split such that at least two leaves that have a common
480	key segment at that level end up in a separate node rooted on that slot for
481	that common key segment.
482	
483	If the leaves in a full node and the leaf that is being inserted are
484	sufficiently similar, then a shortcut will be inserted into the tree.
485	
486	When the number of objects in the subtree rooted at a node falls to 16 or
487	fewer, then the subtree will be collapsed down to a single node - and this will
488	ripple towards the root if possible.
489	
490	
491	Non-Recursive Iteration
492	-----------------------
493	
494	Each node and shortcut contains a back pointer to its parent and the number of
495	slot in that parent that points to it.  None-recursive iteration uses these to
496	proceed rootwards through the tree, going to the parent node, slot N + 1 to
497	make sure progress is made without the need for a stack.
498	
499	The backpointers, however, make simultaneous alteration and iteration tricky.
500	
501	
502	Simultaneous Alteration And Iteration
503	-------------------------------------
504	
505	There are a number of cases to consider:
506	
507	1. Simple insert/replace.  This involves simply replacing a NULL or old
508	   matching leaf pointer with the pointer to the new leaf after a barrier.
509	   The metadata blocks don't change otherwise.  An old leaf won't be freed
510	   until after the RCU grace period.
511	
512	2. Simple delete.  This involves just clearing an old matching leaf.  The
513	   metadata blocks don't change otherwise.  The old leaf won't be freed until
514	   after the RCU grace period.
515	
516	3. Insertion replacing part of a subtree that we haven't yet entered.  This
517	   may involve replacement of part of that subtree - but that won't affect
518	   the iteration as we won't have reached the pointer to it yet and the
519	   ancestry blocks are not replaced (the layout of those does not change).
520	
521	4. Insertion replacing nodes that we're actively processing.  This isn't a
522	   problem as we've passed the anchoring pointer and won't switch onto the
523	   new layout until we follow the back pointers - at which point we've
524	   already examined the leaves in the replaced node (we iterate over all the
525	   leaves in a node before following any of its metadata pointers).
526	
527	   We might, however, re-see some leaves that have been split out into a new
528	   branch that's in a slot further along than we were at.
529	
530	5. Insertion replacing nodes that we're processing a dependent branch of.
531	   This won't affect us until we follow the back pointers.  Similar to (4).
532	
533	6. Deletion collapsing a branch under us.  This doesn't affect us because the
534	   back pointers will get us back to the parent of the new node before we
535	   could see the new node.  The entire collapsed subtree is thrown away
536	   unchanged - and will still be rooted on the same slot, so we shouldn't
537	   process it a second time as we'll go back to slot + 1.
538	
539	.. note::
540	
541	   Under some circumstances, we need to simultaneously change the parent
542	   pointer and the parent slot pointer on a node (say, for example, we
543	   inserted another node before it and moved it up a level).  We cannot do
544	   this without locking against a read - so we have to replace that node too.
545	
546	   However, when we're changing a shortcut into a node this isn't a problem
547	   as shortcuts only have one slot and so the parent slot number isn't used
548	   when traversing backwards over one.  This means that it's okay to change
549	   the slot number first - provided suitable barriers are used to make sure
550	   the parent slot number is read after the back pointer.
551	
552	Obsolete blocks and leaves are freed up after an RCU grace period has passed,
553	so as long as anyone doing walking or iteration holds the RCU read lock, the
554	old superstructure should not go away on them.
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.