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

tx_byte_pool service fragmentation problem #371

Open
SeeDeer opened this issue Mar 10, 2024 · 3 comments
Open

tx_byte_pool service fragmentation problem #371

SeeDeer opened this issue Mar 10, 2024 · 3 comments
Labels
bug Something isn't working hardware New hardware or architecture support request

Comments

@SeeDeer
Copy link

SeeDeer commented Mar 10, 2024

Test method:

  1. Thread A allocate memory blocks in a 1ms cycle (size takes a random value of 11024). When allocate fails, the thread is suspended; 2. Thread B release memory blocks in a 110ms cycle. When all memory blocks are released, Restore thread A.

image

As shown in the above test results,

tx_byte_allocate fail, rt:0x10 size:859 frag:208 available:2068
memory msg, frag:208 available:50184
memory msg, frag:208 available:98276
all memory be release, frag:208 available:102392

All memory blocks have been released, why is the frag field not reduced? Are memory blocks at adjacent addresses not merged?

Looking forward to your reply, thank you.

@SeeDeer SeeDeer added bug Something isn't working hardware New hardware or architecture support request labels Mar 10, 2024
@xray-bit
Copy link

Adjacent free memory blocks are merged together during a subsequent allocation search for a large enough free memory block. This process is called defragmentation.

https://learn.microsoft.com/en-us/azure/rtos/threadx/chapter3#memory-byte-pools

@amgross
Copy link

amgross commented Mar 11, 2024

As @xray-bit says, the defragmentation happens upon allocation scheme and not free scheme.

This is because in free time there is no need to waste time to look on other blocks, while in allocation time we anyway go block after block to find one that is big enough so meanwhile we also merge consecutive free blocks till we find big enough block and stop.

@SeeDeer
Copy link
Author

SeeDeer commented Mar 15, 2024

OK, thanks for your reply.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working hardware New hardware or architecture support request
Projects
None yet
Development

No branches or pull requests

3 participants