-
Notifications
You must be signed in to change notification settings - Fork 44
server: reuse checkpoint state buffers from a bounded pool #201
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
ee6555a
468cf0b
375237a
0418493
1db6cb3
00ce29b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1767,12 +1767,19 @@ server_prompt_cache_state * server_prompt_cache::alloc(const server_prompt & pro | |
| } catch (const std::bad_alloc & e) { | ||
| SRV_ERR("failed to allocate memory for prompt cache state: %s\n", e.what()); | ||
|
|
||
| // limit_size does not count pooled bytes, so both trims are needed: the first releases | ||
| // what was already pooled, the second the buffers update() just evicted, which the | ||
| // checkpoint destructors hand to the pool rather than to the allocator. | ||
| common_state_buffer_pool::instance().trim(0); | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
When memory is tight and the cache-entry removals above have just returned large checkpoint buffers to the new pool, these buffers can be the reason Useful? React with 👍 / 👎. |
||
|
|
||
| limit_size = std::max<size_t>(1, 0.4*size()); | ||
|
|
||
| SRV_WRN(" - cache size limit reduced to %.3f MiB\n", limit_size / (1024.0 * 1024.0)); | ||
|
|
||
| update(); | ||
|
|
||
| common_state_buffer_pool::instance().trim(0); | ||
|
|
||
| return nullptr; | ||
| } | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a Linux container whose cgroup limit is substantially smaller than host RAM, this cap is based on host-wide physical memory: the CPU backend implementation in
ggml/src/ggml-cpu/ggml-cpu.cppobtainsmem_totalfromsysconf(_SC_PHYS_PAGES)without consulting cgroups. For example, a 4 GiB pod on a 256 GiB host can therefore retain up to 16 GiB of resident checkpoint buffers, allowing the cgroup OOM killer to terminate the server before the advertised bound or idle trimming helps. The cap needs to incorporate the process/container memory limit when one is present.Useful? React with 👍 / 👎.