Hi Henning, Indeed, it will be interesting to run the such tests, but some major advantages we have with the current mem manager: 1) in private memory, we have no locking. Malloc from glibc does all the time lock in order to be thread safe 2) debugging possibilities - I know there are hundreds of tools for doing this, but we have it built in and better tuned for openser 3) runtime inspection - mem usage, fragments,
Anyhow, we will never be able to drop the internal openser mem manager as it is mandatory for shm memory ;) Regards, Bogdan Henning Westerholt wrote: > On Thursday 07 February 2008, Dan Pascu wrote: > >>> Well ....do not take me as a performance maniac :D...As I said, it is >>> not about performance but about functionality - memory fragmentation is >>> something serious and we should try to avoid it as much as possible. >>> >> As a side note to the discussed issue, I don't think it is realistic to >> assume that memory fragmentation will not occur by just avoiding some DB >> memory allocations that vary in size too much. Given the varying size of >> SIP requests, over time, if the proxy is online for a long time and >> servicing many requests per second, memory fragmentation will occur >> sooner or later, unless the memory allocator is smart and works around >> it, or if it has a defragmentor that is run when memory gets too >> fragmented. >> > > It would be interesting to run OpenSER on a recent kernel with a recent glibc > and sees how the performance figures of the standard malloc compares now > against the internal f_malloc. The memory allocator in the kernel was > reworked quite a few times, and some work have been done in the active > defragmentation area (but i'm not sure if this have been merged yet). > > Cheers, > > Henning > > _______________________________________________ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel