TDB eviction and stale response processing #2074
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
const-t
force-pushed
the
kt-522-eviction
branch
2 times, most recently
from
5d4eaf5
to
d02eeaa
Compare
const-t
force-pushed
the
kt-522-eviction
branch
from
d02eeaa
to
53cf2bc
Compare
const-t
force-pushed
the
kt-522-eviction
branch
from
53cf2bc
to
d9d48f0
Compare
const-t
force-pushed
the
kt-522-eviction
branch
from
d9d48f0
to
5bd7df8
Compare
This was
linked to
issues
Jun 17, 2024
const-t
force-pushed
the
kt-522-eviction
branch
5 times, most recently
from
00dffd7
to
67b01fb
Compare
EvgeniiMekhanik
requested changes
Jul 5, 2024
Few `tdb_get_blk()` moved to `tdb_alloc_blk()`, however we still use `tdb_get_blk()` outside block allocation.
Now in cache we don't lock cache entry, we just reference count it. Relying on that fact this patch introduce new approach for storing stale response, without building it each time when we have stale record in the cache. Simply find the record in the cache, save it to `TfwHttpReq` as `stale_ce` and keep the reference. If `stale_ce` was not used, just put the the reference, if it needed just build the response then put the reference and forward response to client.
To not introduce additional function call to cache.h and do not introduce additional flags we set `TFW_HTTP_CC_STALE_IF_ERROR` flag for request when cached response has this flag. This is safe, because at the moment of using `tfw_http_resp_should_fwd_stale` it doesn't metter request or response had such flag. Becasue timeout already checked in `tfw_cache_can_use_stale` for both request and response and we just need to know either request or response had flag.
Added missed `tdb_rec_put()`, record must be released in both cases when cache entry copied correctly and error occurred during copying
We increase statistics only when record is complete, thus we must decrease it always when complete as well.
To solve following issue, was added global freelist of blocks: Due to per-CPU nature of freelist, block can be allocated only on CPU where it was freed. It can cause allocation failures in case when one CPU frees more blocks then others and free blocks available only in per-CPU freelists because main memory pool is exhausted. Global freelist is used only when pcp-list is empty and main memory is exhausted. Do like so to minimize contention while main memory still available. Also added flag that indicates out of main memory, in this case we use only pcp lists and don't try, to allocate from main memory.
Changed precedence of allocation, now we allocate record and only if record was allocated we try to allocate bucket, if bucket allocation fails frees the record. In the burst function changed clean up related part, now we clean `free_nb` on each allocation failure, because we need to free previously successfully allocated records.
-Removed debug ifdef -Fix double put for 304 stale -Added proper error handling in `tfw_client_start()` and `tfw_http_resp_fwd_stale()` -TFW_HTTP_CC_STALE_IF_ERROR added to BUG_ON. -cache_req_process_node() devided into two pathes: first for stale and second for fresh responses.
-Proper error handling during forwarding stale resposne -`tdb_rec_put(client_db, rec);` moved little bit down -`allow_repeat` changed to false
Added error injection and now we don't free response on eror in `__tfw_http_resp_fwd_stale()` we let `tfw_http_conn_drop()` do that.
Add error response sending if response not allocated succcessfully
const-t
force-pushed
the
kt-522-eviction
branch
from
aa0a993
to
facfd38
Compare
When Tempesta forwards stale response, it free original response and replace it with new one from the cache then drops connection with upstream server. However, Tempesta continues to process input skbs and call `tfw_http_resp_process()` for them, that may lead to crash. To prevent that just mark connection with `Conn_Stop` flag .
const-t
force-pushed
the
kt-522-eviction
branch
from
e15be42
to
9da77cb
Compare
This was
linked to
issues
Nov 15, 2024
Closed
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Wiki branch related to this PR is
kt-use-stale-desc