- 04 Feb, 2024 30 commits
-
-
Nils Goroll authored
This allows us to shrink the fellow_cache_obj allocation for the fellow_obj_get (from disk) case from 8KB to 512 bytes. The root cause for the massively oversized fco allocation was that the nseg_guess heuristic could not take into account the wsl (size of the actual object), so it had to assume that all of the disk object's size was taken up for segments in the disk object embedded seglist.
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
Share the mempool between reading (flc) and writing (logbuffer). Use different mempools and priorities for log rewrite and log flushes.
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
the logcache should know the best size
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
The previous implementation used only one BUDDY_REQS, so whenever one segment allocation was fulfilled, other requests with lower priority could "get through" and ultimately lead to bfa_alloc() failing to complete. By using two BUDDY_REQS, we now make sure to "keep out place in the priority queue". We also limit cramming not only by the available bitfield segment slots, but also by a maximum of 4 (1/16th of the requested size) and yield when a lower cram does not succeed to motivate LRU more to make room. This has undergone a _lot_ of testing and has gone through many iterations, which all have been squashed into this commit.
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
since https://github.com/varnishcache/varnish-cache/pull/3855/files was merged a long time ago and we never supported 7.2 in a public release.
-
Nils Goroll authored
-
Nils Goroll authored
based on insights with minimum memory testing, we need even more fine grained priorities. The main insight is that new objects get lower priorities than rewrite-related allocations, but once they exist, their subordinate requests for segments and metadata get higher priorities. We now also re-assign the priority of waiting allocations. DLECHK gets a top priority because it uses small allocations and is vital for rewrite progress.
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
When we hit an FCO for which we could not lock the varnish object (oc), we inserted that FCO at the end of the LRU list, and restarted at the first. But if that FCO was the only one, we would find ourselves in an infinite loop. We now put a marker segment on the LRU for the time we need to let go of the lru lock and continue at that marker.
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
The exp thread is also critical. It must not starve, otherwise lru starves also because of hitting OC_F_DYING objects.
-
Nils Goroll authored
-
- 03 Feb, 2024 10 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-