Am 23.01.2007 um 16:24 schrieb Stephen Deasey:
I thought the goal was less memory fragmentation -- not necessarily speed which was pretty good with zippy -- and fragmentation was solved by using mmap for memory which could be returned to the system.
Well, we wouldn't like to be slower than zippy. At least not more than 25%. Returning the memory to the system is now relatively suboptimal as it happens only on thread exit which is problematic for threads that never exit (driver.c).
So fragmentation is only a problem for small allocations, in the real world?
Mostly yes.
Also, why did you choose this strategy, using the system malloc for > 8000b, rather than modify the way the per thread mmap pools are released to the OS. This used to be on thread exit, right? If this was causing bloating in long-lived threads, you could flush the pool when some low water mark is reached.
One after another... this is still on the todo list of mine. It requires quite a bit of testing and needs time. Coding is simple, testing is complex. The limitation to 8K was simple way to get less bloating with large concurrent number of threads. But we'd still have to return memory to the system or for reusal to other threads more agressively than we do now. The tricky part is to find the optimum between the speed and the memory consumption, having in mind the typical usage patterns that we encounter in naviserver and applications built on top of it.
