Remove guard pages from fibers and alternative stack for signals in threads

[CheSema]

Changelog category (leave one):

• CI Fix or Improvement (changelog entry is not required)

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

Remove guard pages for threads and async_socket_for_remote/use_hedge_requests. Change the allocation method in FiberStack from mmap to aligned_alloc. Since this splits VMAs and under heavy load vm.max_map_count can be reached.

Documentation entry for user-facing changes

• Documentation is written (mandatory for new features)

[clickhouse-gh]

Workflow [PR], commit [93312bd]

[canhld94]

Same effort in #73510. In upstream PR we use mmap for fallback if cache is full, but in internal branch we've already switched to allocator.
I think it's still important to have some stacks with guarded page to catch stack overflow (though it will rarely happens).

[azat]

FiberStack allocates its stack with allocator. Ir previously used mmap call for it.
Also the stack is protected with guarded page only in debug build.

You did it not only for fibers, so let's adjust the PR description and title

[azat]

I think it's still important to have some stacks with guarded page to catch stack overflow (though it will rarely happens).

This is a good idea with respect to how many times we increased the stack size for fibers:

• f07918c
• 37286c6
• ba18ba1
• d9ca1e2
• f3319cd

@CheSema WDYT? Maybe we just need to proceed with #73510 them?

@canhld94 we can avoid using mmap at all and simply install guard pages inside the aligned allocation, should work

[CheSema]

I think it's still important to have some stacks with guarded page to catch stack overflow (though it will rarely happens).

This is a good idea with respect to how many times we increased the stack size for fibers:

• f07918c
• 37286c6
• ba18ba1
• d9ca1e2
• f3319cd

Sema Checherinda WDYT? Maybe we just need to proceed with #73510 them?

Duc Canh Le we can avoid using mmap at all and simply install guard pages inside the aligned allocation, should work

This PR is created as a fix for an issue.
There won't be any new functionality or unnecessary changes.
The change about should or should not CurrentMemoryTracker take into account the guarded page is already unnecessary change here, but I share the same opinion here as you, we should account that page.

Make guarded pages with some probability in release is great idea. We could do it after.

Cache for allocations. Also good idea. I have some question there. It is already in progress, it would be discussed and merged in its PR.

[azat]

@CheSema the description is too low level, how about something like this?

Remove guard pages for threads and async_socket_for_remote/use_hedge_requests. Since this splits VMAs and under heavy load vm.max_map_count can be reached.

[canhld94]

Make guarded pages with some probability in release is great idea. We could do it after.

I think we just need a pool of stacks with guard page, when the pool is full, we use normal allocator.

[azat]

LGTM (don't forget to update the PR title, right now it says only about fibers)