At Tue, 16 Jul 2013 13:11:00 +0300 (EEST), Kirill A. Shutemov wrote: > > Andi Kleen wrote: > > From: Andi Kleen <[email protected]> > > > > glibc calloc() has an optimization to not explicitely memset() > > very large calloc allocations that just came from mmap(), > > because they are known to be zero. > > > > This could result in the perf memcpy benchmark reading only from > > the zero page, which gives unrealistic results. > > > > Always call memset explicitly on the source area to avoid this problem. > > > > Cc: [email protected] > > Cc: [email protected] > > Signed-off-by: Andi Kleen <[email protected]> > > --- > > tools/perf/bench/mem-memcpy.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/tools/perf/bench/mem-memcpy.c b/tools/perf/bench/mem-memcpy.c > > index 93c83e3..690f75f 100644 > > --- a/tools/perf/bench/mem-memcpy.c > > +++ b/tools/perf/bench/mem-memcpy.c > > @@ -117,6 +117,8 @@ static void alloc_mem(void **dst, void **src, size_t > > length) > > *src = zalloc(length); > > if (!src) > > die("memory allocation failed - maybe length is too large?\n"); > > + /* Make sure to always replace the zero pages even if MMAP_THRESH is > > crossed */ > > + memset(src, 0, length); > > It should be memset(*src, 0, length) instead. > > There's fix for wrong memory allocation fail check in v3.11-rc1.
I couldn't catch it, thanks. The memset() should be fixed. Thanks, Hitoshi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
