- 07 Feb, 2024 1 commit
-
-
Nils Goroll authored
Before: $ find . -name \*.so| xargs nm|grep simple_task_ 000000000004ffd0 T fellow_simple_task_run After: $ find . -name \*.so| xargs nm|grep simple_task_ <EOF> Motivated by #27
-
- 04 Oct, 2023 10 commits
-
-
Nils Goroll authored
See liburing commit 834496358870cb272f98cf22b3fe0307c83a526d
-
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
Fixes #26 specifically, we are still missing similar handling in other places.
-
- 30 Sep, 2023 17 commits
-
-
Nils Goroll authored
2d468a6f gave the clue: When fellow_cache_obj_lru_touch() raced fellow_cache_lru_work(), we would put the fco's fcs on the lru list twice: once from _touch and then from _lru_work(). Fixes #25
-
Nils Goroll authored
See next commit for fix This reverts commit bf1e9e71. Conflicts: src/fellow_cache.c
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
Conflicts: src/fellow_cache.c
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
Motivated by #25, which looks like a self-induced deadlock in fellow_cache_lru_work()
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
I suspected we could run into an infinite loop here. Suppose there is only one fco on the LRU and we fail to mutate it, then it was re-inserted again and again. Related to #25, but I am not sure yet if it is the root cause
-
Nils Goroll authored
-
Nils Goroll authored
-
- 25 Sep, 2023 2 commits
-
-
Nils Goroll authored
Avoid memory LRU racing disk LRU. Disk LRU uses the varnish-cache LRU facility, which works by setting the OC_F_DYING and gaining one reference, resulting in two references. One is lost again by the thread initiating the LRU nuke, the other by the EXP thread. Between the two events, the refcnt is one again, thus stvfe_mutate could race. I believe this fixes #23 and #24. If not, please reopen
-
Nils Goroll authored
-
- 19 Sep, 2023 10 commits
-
-
Nils Goroll authored
Tests #22
-
Nils Goroll authored
the test case from the next commit exposed a deadlock because the only object in the test would consume all memory und could not get LRUd because fellow_cache_async_write_complete() would hold the fco mtx during log submission.
-
Nils Goroll authored
UINT16_MAX would be just over a disk block, and allocating another 3.93k for a single additional segment does not make sense. (gdb) p /x sizeof(struct fellow_disk_seg) * 65534 + sizeof(struct fellow_disk_seglist) $7 = 0x37ffd0 Also fix a potential overflow, where a uint16_t was incremented after clamping to UINT16_MAX.
-
Nils Goroll authored
Tests #22
-
Nils Goroll authored
Fixes another case of #22
-
Nils Goroll authored
Fixes one case for #22
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
fellow_cache_lru_chg() already calls fellow_cache_lru_chgbatch_apply() when the remove array is full.
-