Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kernel: provide aligned variants for allocators #29519

Closed
cfriedt opened this issue Oct 24, 2020 · 2 comments · Fixed by #30363
Closed

kernel: provide aligned variants for allocators #29519

cfriedt opened this issue Oct 24, 2020 · 2 comments · Fixed by #30363
Assignees
Labels
Enhancement Changes/Updates/Additions to existing features

Comments

@cfriedt
Copy link
Member

cfriedt commented Oct 24, 2020

Is your enhancement proposal related to a problem? Please describe.
While it is not really meaningful to provide allocators for arbitrary alignments (1, 2, 3, .., 42) it should certainly be feasible to adjust the existing allocators so that they are able to select memory blocks to return based on alignment criteria.

I think the generally accepted alignment constraints are that the alignment must be a multiple of the word size (i.e. sizeof(void *)).

Describe the solution you'd like

  • modify the allocators in question to accept an alignment parameter and rename
  • create wrapper versions of the old allocators (which request alignment of void *, possibly static inline)
  • adjust the primary allocation routines (It seems like it's mainly in lib/os/mempool.c)

Describe alternatives you've considered

I've only glanced at the allocator in lib/os/mempool.c, and it seems like a buddy allocator with some additional features.

If anyone is knowledgeable about the workings of lib/os/mempool.c, some input would be greatly appreciated on how to efficiently search through the metadata to find a suitably-aligned block.

The approach I've taken for a similar buddy allocator in the past is to look at each available order-N block, and then move to order-N+1, etc, but I don't know if that would be acceptable performance-wise for Zephyr.

Additional context
This will be used for dynamic thread stacks, including #29029

@cfriedt cfriedt added the Enhancement Changes/Updates/Additions to existing features label Oct 24, 2020
@cfriedt cfriedt self-assigned this Oct 24, 2020
@andrewboie
Copy link
Contributor

k_mem_pool_* and sys_mem_pool_* are being removed from the kernel.

@cfriedt cfriedt changed the title kernel: provide alignment variants for k_malloc(), k_mem_pool_malloc(), k_mem_pool_alloc() kernel: provide alignment variants for allocators Oct 25, 2020
@cfriedt cfriedt changed the title kernel: provide alignment variants for allocators kernel: provide aligned variants for allocators Oct 25, 2020
@cfriedt
Copy link
Member Author

cfriedt commented Oct 26, 2020

k_mem_pool_* and sys_mem_pool_* are being removed from the kernel.

Just saw #28611 - now everything makes sense! Thanks ;-)

carlescufi pushed a commit that referenced this issue Dec 27, 2020
This change adds z_heap_aligned_alloc() and k_aligned_alloc()
and changes z_heap_malloc() and k_malloc() to be small wrappers around
the aligned variants.

Fixes #29519

Signed-off-by: Christopher Friedt <[email protected]>
carlescufi pushed a commit that referenced this issue Dec 27, 2020
This change adds tests for k_aligned_alloc.

Fixes #29519

Signed-off-by: Christopher Friedt <[email protected]>
bwasim pushed a commit to bwasim/zephyr that referenced this issue Jan 5, 2021
This change adds z_heap_aligned_alloc() and k_aligned_alloc()
and changes z_heap_malloc() and k_malloc() to be small wrappers around
the aligned variants.

Fixes zephyrproject-rtos#29519

Signed-off-by: Christopher Friedt <[email protected]>
bwasim pushed a commit to bwasim/zephyr that referenced this issue Jan 5, 2021
This change adds tests for k_aligned_alloc.

Fixes zephyrproject-rtos#29519

Signed-off-by: Christopher Friedt <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement Changes/Updates/Additions to existing features
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants