mirror of
https://github.com/zephyrproject-rtos/zephyr
synced 2025-09-02 11:02:28 +00:00
This patch amounts to a mostly complete rewrite of the k_mem_pool allocator, which had been the source of historical complaints vs. the one easily available in newlib. The basic design of the allocator is unchanged (it's still a 4-way buddy allocator), but the implementation has made different choices throughout. Major changes: Space efficiency: The old implementation required ~2.66 bytes per "smallest block" in overhead, plus 16 bytes per log4 "level" of the allocation tree, plus a global tracking struct of 32 bytes and a very surprising 12 byte overhead (in struct k_mem_block) per active allocation on top of the returned data pointer. This new allocator uses a simple bit array as the only per-block storage and places the free list into the freed blocks themselves, requiring only ~1.33 bits per smallest block, 12 bytes per level, 32 byte globally and only 4 bytes of per-allocation bookeeping. And it puts more of the generated tree into BSS, slightly reducing binary sizes for non-trivial pool sizes (even as the code size itself has increased a tiny bit). IRQ safe: atomic operations on the store have been cut down to be at most "4 bit sets and dlist operations" (i.e. a few dozen instructions), reducing latency significantly and allowing us to lock against interrupts cleanly from all APIs. Allocations and frees can be done from ISRs now without limitation (well, obviously you can't sleep, so "timeout" must be K_NO_WAIT). Deterministic performance: there is no more "defragmentation" step that must be manually managed. Block coalescing is done synchronously at free time and takes constant time (strictly log4(num_levels)), as the detection of four free "partner bits" is just a simple shift and mask operation. Cleaner behavior with odd sizes. The old code assumed that the specified maximum size would be a power of four multiple of the minimum size, making use of non-standard buffer sizes problematic. This implementation re-aligns the sub-blocks at each level and can handle situations wehre alignment restrictions mean fewer than 4x will be available. If you want precise layout control, you can still specify the sizes rigorously. It just doesn't break if you don't. More portable: the original implementation made use of GNU assembler macros embedded inline within C __asm__ statements. Not all toolchains are actually backed by a GNU assembler even when the support the GNU assembly syntax. This is pure C, albeit with some hairy macros to expand the compile-time-computed values. Related changes that had to be rolled into this patch for bisectability: * The new allocator has a firm minimum block size of 8 bytes (to store the dlist_node_t). It will "work" with smaller requested min_size values, but obviously makes no firm promises about layout or how many will be available. Unfortunately many of the tests were written with very small 4-byte minimum sizes and to assume exactly how many they could allocate. Bump the sizes to match the allocator minimum. * The mbox and pipes API made use of the internals of k_mem_block and had to be ported to the new scheme. Blocks no longer store a backpointer to the pool that allocated them (it's an integer ID in a bitfield) , so if you want to "nullify" them you have to use the data pointer. * test_mbox_api had a bug were it was prematurely freeing k_mem_blocks that it sent through the mailbox. This worked in the old allocator because the memory wouldn't be touched when freed, but now we stuff list pointers in there and the bug was exposed. * Remove test_mpool_options: the options (related to defragmentation behavior) tested no longer exist. Signed-off-by: Andy Ross <andrew.j.ross@intel.com> |
||
---|---|---|
.. | ||
api | ||
application | ||
contribute | ||
crypto | ||
drivers | ||
getting_started | ||
introduction | ||
kernel | ||
porting | ||
reference/kconfig | ||
scripts | ||
static | ||
subsystems | ||
templates | ||
themes/zephyr | ||
conf.py | ||
copyright.rst | ||
glossary.rst | ||
index.rst | ||
LICENSING.rst | ||
Makefile | ||
README.rst | ||
release-notes-1.5.rst | ||
release-notes-1.6.rst | ||
release-notes-1.7.rst | ||
release-notes.rst | ||
zephyr.doxyfile |
:orphan: Welcome to Zephyr Kernel ######################## .. This document is in Restructured Text Format. Find more information regarding the ReST markup in the `ReST documentation`_. This is a comment that won't show up in formatted output Welcome to the Zephyr Project. Thank you for your interest in the Zephyr Project. These instructions are designed to walk you through generating the Zephyr Project's documentation. Documentation Notes ******************* Zephyr Project content is written using the reStructuredText markup language (.rst file extension) with Sphinx extensions, and processed using sphinx to create a formatted stand-alone website. Developers can view this content either in its raw form as .rst markup files, or you can generate the HTML content and view it with a web browser directly on your workstations drive. This same .rst content is also fed into the Zephyr Project's public website documentation area (with a different theme applied). You can read details about reStructuredText and about Sphinx extensions from their respective websites. The project's documentation currently comprises the following items: * ReStructuredText source files used to generate documentation found at https://zephyrproject.org/doc website. Most of the reStructuredText sources are found in the ``/doc`` directory, but there are others stored within the code source tree near their specific component (such as ``/samples`` and ``/boards``) * Doxygen-generated material used to create all API-specific documents also found at https://zephyrproject.org/doc * Script-generated material for kernel configuration options based on kconfig files found in the source code tree * Additional material on https://wiki.zephyrproject.org The reStructuredText files are processed by the Sphinx documentation system, and make use of the breathe extension for including the doxygen-generated API material. Additional tools are required to generate the documentation locally, as described in the following sections. Installing the documentation processors *************************************** Our documentation processing has been tested to run with: * Doxygen version 1.8.10 (and 1.8.11) * Sphinx version 1.4.4 (but not with 1.5.1) * Breathe version 4.4.0 * docutils version 0.12 (0.13 has issues with Sphinx 1.4.4) Begin by cloning a copy of the git repository for the zephyr project and setting up your development environment as described in :ref:`getting_started` or specifically for Ubuntu in :ref:`installation_linux`. (Be sure to export the environment variables ``ZEPHYR_GCC_VARIANT`` and ``ZEPHYR_SDK_INSTALL_DIR`` as documented there.) Here are a set of commands to install the documentation generations tools on Ubuntu: .. code-block:: bash $ sudo apt-get install python-pip $ pip install --upgrade pip $ sudo apt-get install doxygen $ pip install sphinx==1.4.4 $ sudo -H pip install breathe $ sudo -H pip install sphinx-rtd-theme There is a known issue that causes docutils version 0.13 to fail with sphinx 1.4.4. Verify the version of docutils using: .. code-block:: bash $ pip show docutils If this shows you've got version 0.13 of docutils installed, you can install the working version of docutils with: .. code-block:: bash $ sudo -H pip install docutils==0.12 Running the Documentation Generators ************************************ The ``/doc`` directory in your cloned copy of zephyr project git repo has all the .rst source files, extra tools, and Makefile for generating a local copy of the Zephyr project's technical documentation. Assuming the local Zephyr project copy is ``~/zephyr``, here are the commands to generate the html content locally: .. code-block:: bash $ cd ~/zephyr $ source zephyr-env.sh $ make htmldocs The html output will be in ``~/zephyr/doc/_build/html/index.html`` .. _ReST documentation: http://sphinx-doc.org/rest.html