Memory pool issue

[jasonedn]

Describe the bug
Four (number of maximum-size blocks=4)  are defined, but only two available. Why?

What have you tried to diagnose or workaround this issue?

To Reproduce
Steps to reproduce the behavior:

1. mkdir build; cd build
2. cmake -DBOARD=board_xyz
3. make
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Impact
What impact does this issue have on your progress (e.g., annoyance, showstopper)

Logs and console output
If applicable, add console logs or other types of debug information
e.g Wireshark capture or Logic analyzer capture (upload in zip archive).
copy-and-paste text and put a code fence (```) before and after, to help
explain the issue. (if unable to obtain text log, add a screenshot)

Environment (please complete the following information):

• OS: (e.g. Linux, MacOS, Windows)
• Toolchain (e.g Zephyr SDK, ...)
• Commit SHA or Version used

Additional context
Below are the test codes.

#include <zephyr.h>
#include <sys/printk.h>
#include <kernel.h>

#define MEM_POOL_MIN_BLOCK_SIZE  ( 4 * 4 )
#define MEM_POOL_MAX_BLOCK_SIZE  ( 4 * MEM_POOL_MIN_BLOCK_SIZE )
#define MEM_POOL_MAX_BLOCK_NUM   ( 4 ) 		  

K_MEM_POOL_DEFINE( myPool, MEM_POOL_MIN_BLOCK_SIZE, MEM_POOL_MAX_BLOCK_SIZE, MEM_POOL_MAX_BLOCK_NUM, 4 );

void printError( int error )
{
	switch ( error ) {
	case 0:
		printk("ok\n");
		break;

	case -ENOMEM:
		printk("no memory\n");
		break;

	case -EAGAIN:
		printk("timeout\n");
		break;			

	default:
		printk("Unknown error\n");
		break;
	}
}

void main(void)
{
	printk("kernel memory pool!\n" );

	int err;
	size_t size = MEM_POOL_MAX_BLOCK_SIZE;
	printk( "Allocating %d from memory pool...", size );
	struct k_mem_block block1;

	err = k_mem_pool_alloc( &myPool, &block1, size, K_MSEC(100) );
	if ( err == 0 ) {
		printError( err );
		memset( block1.data, 0, 200);

		struct k_mem_block block2;
		size = MEM_POOL_MAX_BLOCK_SIZE;
		printk( "Allocating %d from memory pool...", size );
		err = k_mem_pool_alloc( &myPool, &block2, size, K_MSEC(100) );
		if ( err == 0 ) {
			memset( block2.data, 0, 200);
		} 
		printError( err );		

		struct k_mem_block block3;
		size = 1*MEM_POOL_MIN_BLOCK_SIZE;
		printk( "Allocating %d from memory pool...", size );
		err = k_mem_pool_alloc( &myPool, &block3, size, K_MSEC(100) );
		if ( err == 0 ) {
			memset( block3.data, 0, 200);
		} 
		printError( err );		
		
		struct k_mem_block block4;
		size = 1*MEM_POOL_MIN_BLOCK_SIZE;
		printk( "Allocating %d from memory pool...", size );
		err = k_mem_pool_alloc( &myPool, &block4, size, K_MSEC(100) );
		if ( err == 0 ) {
			memset( block4.data, 0, 200);
		} 
		printError( err );		

		k_mem_pool_free( &block1 );
		k_mem_pool_free( &block2 );
		k_mem_pool_free( &block3 );
		k_mem_pool_free( &block4 );
	} else {
		printError( err );
	}
}

Below are the test results:

*** Booting Zephyr OS version 2.4.0-rc3  ***
kernel memory pool!
Allocating 64 from memory pool...ok
Allocating 64 from memory pool...ok
Allocating 16 from memory pool...timeout
Allocating 16 from memory pool...timeout

The last two allocations should be ok but they fail. I'm not sure I'm not using them correctly or this is a bug for the memory pool.

[andyross]

Is this with CONFIG_HEAP_MEM_POOL_BACKEND=n? Note that the mem_pool allocator is about to be deprecated, and the default backend is no longer a sys_mem_pool at all but a sys_heap, which is a general purpose allocator.

This new allocator works differently (it just manages a contiguous region of memory with no "blocks" abstraction), but there was supposed to be some logic in the K_MEM_POOL_DEFINE macro that emulated the right size so that expectations like this would still hold. It's possible that broke, it got modified at one point.

But broadly: please use a k_heap. That older API is going away.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[andyross]

Closing this one. We've now removed the whole mem_pool API.