https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241848
--- Comment #16 from Mark Millard <[email protected]> --- (In reply to Dimitry Andric from comment #15) I'll note one possibility may be jemalloc behavior contributing. (Not that I've specific evidence one way or the other.) QUOTING (although I changed the top-post order to bottom posting) . . . On Thu, Jan 9, 2020 at 1:45 PM Bryan Drewery <bdrewery at freebsd.org> wrote: > > Do you plan to get this back in soon? I hope to see it before 12.2 if > possible. Is there some way I can help? > > I'm interested in these changes in 5.2.1 (I think) > - Properly trigger decay on tcache destroy. (@interwq, @amosbird) > - Fix tcache.flush. (@interwq) > - Fix a side effect caused by extent_max_active_fit combined with > decay-based purging, where freed extents can accumulate and not be > reused for an extended period of time. (@interwq, @mpghf) > > I have a test case where virtual memory was peaking at 275M on 4.x, 1GB > on 5.0.0, around 750M on 5.1.0, and finally 275M again on 5.2.0. The > 5.0/5.1 versions appeared to be a widespread leak to us. . . . I think it's fine to get jemalloc 5.2.1 in again now. The previous fails were due to ancient gcc421. Now the in-tree gcc has been removed and the default compiler of non-llvm platforms are all using gcc6 from ports. The CI environment are also updated to follow the current standard. I've tested a patch combines r354605 + r355975 and it builds fine on amd64 (clang10) and mips (gcc6). Best, Li-Wen -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
