Max num is supposed to be the maximum architectural limit supported.
This sounds like an implementation bug. The system should not reserve
the maximum but should be designed to expand up to the maximum
(subject to memory availability). I agree 272MB is excessive as a
fixed overhead even for datacenter servers.
On Mon, Dec 12, 2016 at 10:44 AM, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
> The latest pool changed set huge pool_table_t. That is due to:
>
> #define CONFIG_POOL_MAX_NUM (1 * 1024 * 1024)
>
> If for example it's
> #define CONFIG_POOL_MAX_NUM (4096)
>
> Then pool_table_t is 18M.
>
>
> Allocation happens here:
> int odp_pool_init_global(void)
> {
>
> shm = odp_shm_reserve("_odp_pool_table",
> sizeof(pool_table_t),
> ODP_CACHE_LINE_SIZE, 0);
>
> ...
>
>
> Because of with latest changes in api-next for process mode and drivers
> mapping file in /tmp/ directory is created. So for each process there is
> 272M file. I think that is too big and can be a problem with testing on
> small machines.
>
> 1. Can we lower that number of maximum entries in the pool?
>
> 2. Can we remove that table from here completely and made it dynamic in
> odp_pool_create()?
>
> Thank you,
> Maxim.
