[LTP] [RFC PATCH] madvise06: shrink to 1 MADV_WILLNEED page to stabilize the test

[Li Wang]

Hi Richard,

Richard Palethorpe <rpalethorpe@suse.de> wrote:


> >  Adding the loop makes sense to me. However I don't understand why you
> >  have also switched from PASS_THRESHOLD to only a single page?
> >
> > In the test, we use two checks combined to confirm the bug reproduces:
> >
> >   1. swap cached increasing less than PASS_THRESHOLD_KB
> >   2. page_fault number large than expected
> >
> > The 2. case is more easily get failed on kind of platforms and hard
> > to count an average value for tolerating. So maybe we just reduce
> > the page to one that would not affect the final result. Because we
> > rely on both checks happening simultaneously then assume a bug.
> >
> >
> >
> >  I guess calling MADV_WILLNEED on a single page is the least realistic
> >  scenario.
> >
> > Okay, perhaps it's a step backward:).
> >
> > I was just thinking it is a regression test and if 1 page works to
> reproduce
> > that (but more chunks of memory easily cause false positive), why not.
>
> That makes sense, but this test has also found other bugs. I'm not sure
> if they are reproducible with only one page.
>

Indeed.



>
> >
> >
> >
> >  If there is an issue with PASS_THRESHOLD perhaps we could scale it based
> >  on page size?
> >
> > This sounds acceptable too.
> >
> > How many pages do you think are proper, 100 or more?
> > and, loosen the faulted-out numbers to 1/10 pages?
>
> I suppose that 100 pages would be too much memory on some systems. I
> guess at least 2 or 3 pages are needed so there is some
> traversal. Beyond that I don't know what would make a difference.
>
> If there are only max 3 pages and we have a loop, I would not expect any
> to be faulted. Although maybe we could allow 1/3 because MADV_WILLNEED
> is only an advisory and a lot of time has been spent discussing this
> test already.
>

It sounds reasonable. Thanks!

I would have a try and go touch 3 pages (with expect 0 page fault) if that
does work.

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20220620/a39e90bc/attachment.htm>