Tony Finch wrote:
> > You are arguing that there is nothing that can account for the
> > performance difference, when in fact there is a measured
> > performance difference.
> 
> No, I'm saying that some of what you said is either wrong or
> misleading, and the comment about security was especially stupid.

Yes, it was misleading, in that I didn't provide full implementation
details, so a naieve reader looking to reimplement malloc() as it was
implemented on FreeBSD, would get it wrong.

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.


I don't think it's necessary to discuss the implementation details
to the level of documenting them for people wanting to reimplement
the code.

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.

Saying this, though, really doesn't help, when you have a user that's
pretending to not understand your explanations, and wants an explanation
in layman's terms, which is what the original poster is facing.

If it weren't for the fact that we were dealing with a programmer that
was pretending to be dumb enough to put allocations into an interior
loop in order to give FreeBSD a bad "performance" number relative to
Linux, this wouldn't have ever been an issue in the first place: for
the "perfectly correct", we would just refer the person to the malloc()
source code.  Instead, we have to deal with a fictional microbenchmark,
and discuss why decisions were made.

There's "perfectly correct", and then there's "speaking to the level
of your audience".


> > > PHK malloc uses MAP_ANON on FreeBSD, not /dev/zero -- it uses the
> > > latter only if compiled for Solaris.
> >
> > And tell me, what does the Linux malloc use?
> 
> Exactly the same, and it uses MAP_ANONYMOUS on Linux. It uses mmap for
> large allocations whereas phk malloc does not. Since both mmap and
> sbrk get zero-filled pages from the kernel this shoudld make little
> difference, except in the calloc case explained above.

The allocations in this case are lots of very small allocations; it
makes no real difference, unless there is a preallocation of space
by the malloc() subsystem in order to refill a free pool, to deal
with expected future malloc() requests.

FreeBSD's "overallocation pool size" is one 4K page, which is relatively
small for modern systems with 4G of memory.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to