Bruno Faccini

@shintaro-iwasaki , I spent some times to write a piece of code to better describe how mmap()'ed stack allocation could be done to allow for some automatic growth up to...

Hello Shintaro, First of all, I had to update my code snippet above as it was wrongly doing a system("cat /proc/self/maps") at the beginning and end, which was a non-sense...

find_hole() code is necessary to ensure that Kernel will let the stack grow from min_stack_size to max_stack_size. And there is no special treatment for MAP_GROWSDOWN during mmap(). I agree with...

Concerning how to ensure that an other mmap()/VMA will take place in the hole between the current top of stack and the previous region at stack allocation time, this is...

> vm.overcommit_memory is not tunable I don't think I ever wrote that "vm.overcommit_memory is not tunable", did I ? For me it is also a tunable, like vm.max_map_count, even if...

You are right when you say that the extra-gap used buy find_hole(), to stand on top of lowest stack address, is not guaranteed to be kept free by the Kernel,...

Hi @shintaro-iwasaki , Humm, I am not sure I understand your last answer, are you saying that we can just use mmap() as the stack allocation mechanism for ULTs stacks,...

Well this is a bit disappointing, but may be at least this issue has permitted you to feel the need for some enhancement around the ULTs stacks allocation/management/protection/....

Hello Shintaro, Since ABT_thread_set_specific() is requiring an ABT_thread parameter, ULT must be a named one. But then its handle must be explicitly freed using ABT_thread_free(). So, how would be the...

Well, seems to me that you did not answer directly to my "Is it safe to also use an ABT_key for this (to free a named ABT_thread) ??" question but...