Petri Savolainen(psavol) replied on github web page:

include/odp/api/spec/init.h
@@ -150,17 +157,29 @@ typedef struct odp_init_t {
            worker and control masks do not overlap.
         */
        const odp_cpumask_t *control_cpus;
+
        /** Replacement for the default log fn */
        odp_log_func_t log_fn;
+
        /** Replacement for the default abort fn */
        odp_abort_func_t abort_fn;
+
        /** Unused features. These are hints to the ODP implementation that
         * the application will not use any APIs associated with these
         * features. Implementations may use this information to provide
         * optimized behavior. Results are undefined if applications assert
         * that a feature will not be used and it is used anyway.
         */
        odp_feature_t not_used;
+
+       /** Shared memory parameters */
+       struct {
+               /** Maximum memory usage in bytes. This is the maximum
+                *  amount of shared memory that application will reserve
+                *  concurrently. */
+               uint64_t max_memory;


Comment:
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_r165579527
updated_at 2018-02-02 09:00:36

Reply via email to