12:31 <koga> | `IPv6 -> Lwt.return_unit (* TODO: oh no! *)

12:34 <koga> ha. he can run, but he cant hide...

12:44 <koga> changed frag cache size to 16kb, deployed in backup role

12:48 <hannes> as i tried to explain, this is _capacity_, not _allocated memory_... but whatever

13:04 <koga> saw that, and yes, whatevs. :)

13:05 <koga> its an easy a/b test to pull

13:08 <hannes> and as usual my brain was wrong ;) thanks to talex5 to provide some sample code ;)

13:09 <koga> "real world memory footprint of an lru cache" is a good one though

13:09 <hannes> i think my aversion against OCaml's hashtables is only growing... ;)

13:10 <koga> use thinly wrapped C++ implementation instead?

13:11 <koga> *hides*

13:11 <hannes> yes of course you get better complexity bounds for common operations than in maps (balanced binary trees) (O(1) -- well, O(hashfn) -- against O(log n)), but its mutable nature and unexpected memory consumption (on create/resize) is just too hard to reason about

13:11 <koga> the main impact of changing the cache size to 16k seems to be that it doesnt work anymore _and_ doesnt print mem stats. (pretends to be working, but there is no relevant throughput)

13:12 <hannes> oh?

13:12 <hannes> i don't believe you

13:15 <koga> (but i guess i can stop my random flailing around)

13:15 <hannes> ?

13:16 <koga> cranking the size up/down was a test to see if it is related to the cache. i think talexs example shows that is the case.

13:39 <koga> (stalling was traffic dest running out of space)

13:40 <hannes> ah, good :)

13:40 <koga> sortof. i am not sure i want to know why sometimes zfs stalls instead of returning EITSTOOBIG ...

13:41 <hannes> (well, not "good", rather good that reducing it to 16k lead to non-functionality / less performance)