At Thu, 18 Jul 2013 15:43:18 -0700, Andi Kleen wrote: > > From: Andi Kleen <a...@linux.intel.com> > > 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: h.mit...@gmail.com > Cc: kirill.shute...@linux.intel.com > v2: Actually memset the right area and also fix the NULL check before. > Signed-off-by: Andi Kleen <a...@linux.intel.com> > --- > tools/perf/bench/mem-memcpy.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/tools/perf/bench/mem-memcpy.c b/tools/perf/bench/mem-memcpy.c > index 93c83e3..0887b46 100644 > --- a/tools/perf/bench/mem-memcpy.c > +++ b/tools/perf/bench/mem-memcpy.c > @@ -115,8 +115,10 @@ static void alloc_mem(void **dst, void **src, size_t > length) > die("memory allocation failed - maybe length is too large?\n"); > > *src = zalloc(length); > - if (!src) > + if (!*src)
In the latest mem-memcpy.c, this if (!src) is already fixed as if (!*src). This modification makes applying fail. Thanks, Hitoshi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/