Tony Finch wrote: > You said that Linux doesn't guarantee to zero pages handed from the > system to userland, which is wrong. You've also mentioned the in- > kernel page-zeroing strategy which is irrelevant when comparing > different userland malloc implementations on the same OS.
No. I said: | The FreeBSD malloc guarantees that the pages are zeroed before being | obtained from the system; this is probably the majority of the cost. | It is a security measure, so that you do not leak data from one process | to another through anonymous pages. | | The Linux malloc does not. It has to do with *when the pages are zeroed... *before* being obtained from the system or *at the time they are obtained from the system*. > Hand-waving about the peanut gallery when I am trying to get you to be > more specific about your vague assertions is not helpful. Specificity is counterproductive in the current context. The person was not asking "how does FreeBSD malloc work?". He was asking about relative performance of FreeBSD and Linux. See the original post: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=73677+0+current/freebsd-hackers ...it was Yet Another Bogus MicroBenchmark. > >The context of the current discussion is a FreeBSD admin with Linux > >users bitching at him about core dumps in an overcommit case, where > >he's hitting an administrative limit, and then trying to dereference > >a pointer to a page that has an established mapping, but for which > >there is no page available to act as backing store. > > I'm slightly perplexed about this: his program shouldn't have dumped > core when hitting an administrative limit because it was correctly > checking the return value from malloc(), and he's unlikely to be in > an overcommit situation on a machine with 4GB of RAM when allocating > only 800MB especially when it works with the administrative limit > removed. Perhaps the core came from a different version of the program > what didn't check for errors properly. The alloc succeeded because there was page mapping space available. The pages to back the pages in that space were not allocated until they were referenced. The core dump may have occurred as a result of any demand for memory at all (including a copy on write of a dirty data page or a stack grow). Running the bad program from the original posting on my local machine, however, indicates, that it happened when there was an attempt to dereference it in the compare in the second "for". On a system with different limits, where the limits were enforced, the mapping could be established, with no room left over to obtain backing pages for the region mapped. If this happened, then it would occur in the array pointer dereference for the first element on a new page boundary in the initial "for" loop. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
