[Bf-committers] Seemingly hugepage-related performance issues

Jonas Wielicki j.wielicki at sotecware.net
Fri Nov 23 09:19:51 CET 2012


On 22.11.2012 19:04, Brecht Van Lommel wrote:
> We could try to hold onto memory longer, but I doubt this would help
> and is a bit fishy anyway. It could be nice for this particular case
> but not for others, and it's hard to distinguish when it's a good idea
> to do it.
I see that point. After thinking for it longer, it also seemed difficult
for me to find clear criterions on when to release memory. Although
during bakes, it seems to be reasonable at least to keep it until the
bake is finished. I don't know anything about the internal structure of
blender though.

> The question then becomes how to avoid such fragmentation. On Windows
> we also have issues with memory fragmentation (especially 32 bit), and
> on Linux we're building now with jemalloc which reduces fragmentation.
> The real solution might be to look at each module in Blender and see
> how we can avoid big allocations there, in this case that would mean
> tiled grids probably.
I'm not sure whether you're talking about user space or kernel space
fragmentation here. I'm facing kernel space fragmentation, and I'm not
sure what blender can do about this, except making clear to the OS that
it'll need the same amount of memory in a few seconds again (by not
releasing it at all).

Thanks for your in-depth reply,

More information about the Bf-committers mailing list