Matthew Dillon wrote:
> :The bzero is unnecessary on FreeBSD. Allocated pages start out
> :zero'ed. Part of the performance issue might be that FreeBSD is
> :being asked to zero the pages twice, instead of once.
> malloc() does not guarentee a zero'd page, even though the
> side effect of a malloc() that large could very well be to map
> demand-zero-fill space.
For his particular test, all the pages come that way.
> The bzero() will have the effect of force-instantiating the
> storage for the malloc'd space. It's appropriate for the
> test, I suppose, since the test is trying to test swap
Maybe. If so, it's not really something that belongs in
the time calculation, I think, unless he's testing the
instantiation, rather than the swapping speed... which is
what he said he was testing.
> :It might be more interesting to mmap() anonymous memory
> :(e.g. out of /dev/zero), rather than using malloc, and
> :then use that memory the same way, instead (it's swap
> :backed, as well). Giving it an madvise, to tell it your
> :intended access pattern would also be useful.
> Just mmap(... MAP_ANON...). It will make no difference,
> though, because that is effectively what a malloc() of
> that size will do anyway.
It gets all the malloc() code out of the code path, so we
can tell if it's a slow malloc or a slow swap... basically,
it makes it more likely he is measuring what he says he is
intent on measuring.
The other issue is that the bzero is definitely not needed
in that case.
The access pattern is actually pessimal; it avoids all of
the sequential access optimizations, at the same time not
disabling FreeBSD's looking for them.
If the code were to mmap() and still bzero(), then it
should madvise() sequential for the bzero, and then
re-madvise() for the pessimal modification/access phase,
so that FreeBSD didn't attempt to look for things to
All in all, it's a test for the degenerate case; but I'm
trying very hard not to just throw it out as a dumb thing
to do, and play the game in figuring out why it's slow,
and if it's really measuring swap performance, or malloc
or bzero or whatever performance.
Hell, part of the issue might be the use of the fprintf()
paging the stdio buffer back in, when using a write()
would avoid the problem entirely. ;^).
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message