Bill Fischofer(Bill-Fischofer-Linaro) replied on github web page:
test/validation/api/shmem/shmem.c
@@ -212,6 +214,55 @@ void shmem_test_basic(void)
CU_ASSERT(0 == odp_shm_free(shm));
}
+/*
+ * maximum size reservation
+ */
+static void shmem_test_max_reserve(void)
+{
+ odp_shm_capability_t capa;
+ odp_shm_t shm;
+ uint64_t size, align;
+ uint8_t *data;
+ uint64_t i;
+
+ memset(&capa, 0, sizeof(odp_shm_capability_t));
+ CU_ASSERT_FATAL(odp_shm_capability(&capa) == 0);
+
+ CU_ASSERT(capa.max_blocks > 0);
+
+ size = capa.max_size;
+ align = capa.max_align;
+
+ /* Assuming that system has at least MAX_MEMORY_USED bytes available */
+ if (capa.max_size == 0 || capa.max_size > MAX_MEMORY_USED)
+ size = MAX_MEMORY_USED;
+
+ if (capa.max_align == 0 || capa.max_align > MEGA)
+ align = MEGA;
Comment:
Same story as for `capa.max_size`. I'd expect most implementations to return
`capa.max_align` to be either 0 or some reasonable value like 4K or 1M.
However, if they specify something else then they should be able to deliver
that.
> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> If the implementation doesn't have a specific predefined upper limit then it
> should return `capa.max_size == 0`. If it says it has a non-zero upper limit
> then if it's unable to provide that limit that's a failure. Otherwise what's
> the point of having a specified limit?
>> Petri Savolainen(psavol) wrote:
>> I'll add comment about zero value. Although, I already changed documentation
>> to require param_init() call and say that don't change values that you are
>> not going to use (init sets it to zero).
>>> Petri Savolainen(psavol) wrote:
>>> OK
>>>> Petri Savolainen(psavol) wrote:
>>>> Very large align could result very large allocation and thus again system
>>>> run out of memory (e.g. 1TB align => >1TB alloc).
>>>>
>>>> OK. I'll change align max to be a power of two.
>>>>> Petri Savolainen(psavol) wrote:
>>>>> Since actual amount of available memory typically depends on system load.
>>>>> SHM implementation may not have a limit (max_size==0), or limit may be
>>>>> due to address space (e.g. 40bit == 1TB). System might not have always
>>>>> the max amount (e.g. 1TB) available. I limit validation test to assume
>>>>> that at least 100MB should be always available.
>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>> @muvarov `odp_shm_capability()` already tells the application the
>>>>>> largest contiguous size it can reserve (`max_size`) and the maximum
>>>>>> number of reserves it can do (`max_blocks`). This is just hinting to the
>>>>>> implementation the total size of all reserves the application will do.
>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>> An additional `printf()` giving a bit more detail (i.e., `i` value)
>>>>>>> would be useful here.
>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>> Shouldn't `MEGA` be a power of 2 for alignment purposes? I.e., 1024 x
>>>>>>>> 1024 rather than 1000 x 1000? And if the implementation supports an
>>>>>>>> even higher `max_align` why not test that as well?
>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>> Why do you want to limit the size in a test that named
>>>>>>>>> `shmem_test_max_reserve()`? If `capa.max_size == 0` then you have to
>>>>>>>>> pick a specific target, but if it's non-zero why wouldn't you want to
>>>>>>>>> try to reserve that much to see if the limit is true?
>>>>>>>>>> muvarov wrote
>>>>>>>>>> 0 - means not specified. And what about continuous of memory chunks?
>>>>>>>>>> Requesting one big continues shared memory chunk is not general
>>>>>>>>>> solution.
https://github.com/Linaro/odp/pull/446#discussion_r165635663
updated_at 2018-02-02 12:46:33
