Thus spake Poul-Henning Kamp <[EMAIL PROTECTED]>: > In message <[EMAIL PROTECTED]>, David Schultz writes: > > >You can find a somewhat more thorough comparison of malloc > >implementations at http://citeseer.nj.nec.com/440671.html . > > There are many problems with this paper, and my feeling is that it was > written with a very specific purpose in mind, although I havn't been > able to figure out just what that purpose was.
I did say `somewhat', didn't I? ;-) As I mentioned in the part of my message that you didn't quote, I don't much care for the paper either, but it's the only half-reasonable comparison I know of. I don't think the authors know what they're talking about, but they did collect extensive data for some real world programs, which I assume is valid. I agree that the behavior of the program from the point of view of the VM system is the most important metric. But internal and external fragmentation are also significant issues. Often, these are a result of programmers not understanding how their malloc works. For example, programs that make numerous 2K allocations in phkmalloc will get twice the amount of memory they asked for, and since each chunk is page-aligned, it will be twice as bad for the VM system. A harder problem to solve is fragmentation for long-running servers, where the RSS tends to creep upwards over time as virtual memory fills with holes. There seems to be a fair amount of research on the subject, although I'm not well read on it. The phkmalloc bucket approach seems to work quite well, as the aforementioned paper claims. I'm guessing that one of these days it will have to be modified for threaded applications to reduce false sharing on SMP systems. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
