memtest updates

[Alexander Aring]

On Tue, Oct 27, 2015 at 06:27:42PM +0100, Alexander Aring wrote:
> On Tue, Oct 27, 2015 at 05:54:59PM +0100, Alexander Aring wrote:
> > On Tue, Oct 27, 2015 at 09:29:53AM +0100, Sascha Hauer wrote:
> > > This series has some updates for the memory test. The output and the
> > > code are made more compact and some additional options are added. Also
> > > the remap_range function is reworked.
> > > 
> > 
> ...
> > 
> > What means 0xdeadbeef here?
> 
> okay, I it's guess the pattern argument which doesn't exist anymore.
> 
> I run memtest now with:
> 
> memtest -t -u
> 
> on the RPi and it seems the first progressbar range of "0/3" - "1/3" runs
> faster than the last range of "1/3" - "3/3".
> 
> This sounds like that remap_range does not full manipulate the range
> of page tables (the range at the start address). Okay we can't full use
> the range, because we need to be PAGE_ALIGN, but the whole first range of
> "0/3" - "1/3" sounds not correct for me (it's bigger than PAGE_ALIGN).
> 
> Maybe everything is correct and the first address room is always a
> little bit faster than the others, but I don't think that.
> 
> I haven't tried to debug this issue. Can somebody confirm that on an
> other arm board?
> 

okay, false alarm. It's confusing me, we do not always the same
operation in each progressbar step.

We doing in the first part filling some pattern, in second/third part we
doing filling pattern and compare. This is why it takes longer. It just
looks like some area is still cached and the other uncached.

- Alex