Terry Lambert <[EMAIL PROTECTED]> wrote: > >The security comment had to do with the fact that zeroing occurs in >the kernel in the idle loop, and can account for a large latency in >the case of a big demand in user space. It's a philosophy issue that >led to the implementation, and it has a performance impact that's >higher in FreeBSD than in Linux, under some usage patterns.
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. Hand-waving about the peanut gallery when I am trying to get you to be more specific about your vague assertions is not helpful. >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. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ IRISH SEA: NORTHWEST BACKING WEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9. SQUALLY SHOWERS. GOOD. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
