From: Li Wang <liwang@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] madvise06: wait a bit after madvise() call
Date: Tue, 19 Jul 2016 16:57:56 +0800 [thread overview]
Message-ID: <20160719085756.GB31704@gmail.com> (raw)
In-Reply-To: <1822250385.6269456.1468911402613.JavaMail.zimbra@redhat.com>
On Tue, Jul 19, 2016 at 02:56:42AM -0400, Jan Stancek wrote:
>
>
> ----- Original Message -----
> > From: "Li Wang" <liwang@redhat.com>
> > To: "Jan Stancek" <jstancek@redhat.com>
> > Cc: ltp@lists.linux.it
> > Sent: Tuesday, 19 July, 2016 7:58:44 AM
> > Subject: Re: [PATCH] madvise06: wait a bit after madvise() call
> >
> > Hi Jan,
> >
> > On Mon, Jul 18, 2016 at 03:37:08PM +0200, Jan Stancek wrote:
> > >
> > > Some other obsverations that are not addressed by this patch:
> > > Testcase assumes that swap is enabled.
> > > Testcase assumes that there is enough swap.
> > > Testcase doesn't check buf[0] is swapped before it calls madvise().
> >
> > It's easy to check swap enabled, but hard to verify one page is swapped. :(
>
> https://www.kernel.org/doc/Documentation/vm/pagemap.txt
>
> >
> > >
> > > diff --git a/testcases/kernel/syscalls/madvise/madvise06.c
> > > b/testcases/kernel/syscalls/madvise/madvise06.c
> > > index 6b081fddf5eb..1b0f58cb319d 100644
> > > --- a/testcases/kernel/syscalls/madvise/madvise06.c
> > > +++ b/testcases/kernel/syscalls/madvise/madvise06.c
> > > @@ -77,6 +77,7 @@ static void test_advice_willneed(void)
> > > char *dst[100];
> > > int page_fault_num_1;
> > > int page_fault_num_2;
> > > + const int pages_to_check = 50;
> > >
> > > /* allocate source memory (1gb only) */
> > > src = safe_mmap(null, 1 * gb_sz, prot_read | prot_write,
> > > @@ -97,18 +98,23 @@ static void test_advice_willneed(void)
> > > tst_res(tinfo, "pagefault(no madvice): %d", get_page_fault_num());
> > >
> > > /* Do madvice() to dst[0] */
> > > - TEST(madvise(dst[0], pg_sz, MADV_WILLNEED));
> > > + TEST(madvise(dst[0], pages_to_check * pg_sz, MADV_WILLNEED));
> > > if (TEST_RETURN == -1)
> > > tst_brk(TBROK | TERRNO, "madvise failed");
> > >
> > > - page_fault_num_1 = get_page_fault_num();
> > > - tst_res(TINFO, "PageFault(madvice / no mem access): %d",
> > > - page_fault_num_1);
> > > -
> > > - *dst[0] = 'a';
> > > - page_fault_num_2 = get_page_fault_num();
> > > - tst_res(TINFO, "PageFault(madvice / mem access): %d",
> > > - page_fault_num_2);
> >
> > 8<---------snip----------------
> > > + i = 0;
> > > + do {
> > > + i++;
> > > + usleep(100000);
> > > +
> > > + page_fault_num_1 = get_page_fault_num();
> > > + tst_res(TINFO, "PageFault(madvice / no mem access): %d",
> > > + page_fault_num_1);
> > > + dst[0][i * pg_sz] = 'a';
> > > + page_fault_num_2 = get_page_fault_num();
> > > + tst_res(TINFO, "PageFault(madvice / mem access): %d",
> > > + page_fault_num_2);
> > > + } while (page_fault_num_1 != page_fault_num_2 && i < pages_to_check);
> > 8<-------------------------------
> >
> > Agree! this method could aviod a wrong diagnosis.
> >
> > But one question is that why involved the 'pages_to_check' as a constant?
> > why not changes like this:
> >
> > int pages_to_check = 50;
>
> Sure, we can do that and save one variable.
>
> > ...
> >
> > while (pages_to_check > 0 && pages_to_check--) {
> > page_fault_num_1 = get_page_fault_num();
> > tst_res(TINFO, "PageFault(madvice / no mem access): %d",
> > page_fault_num_1);
> > dst[0][pages_to_check * pg_sz] = 'a';
> > page_fault_num_2 = get_page_fault_num();
> > tst_res(TINFO, "PageFault(madvice / mem access): %d",
> > page_fault_num_2);
> >
> > if(page_fault_num_1 == page_fault_num_2)
> > break;
> >
> > usleep(100000);
> > }
> >
> >
> > One more word, there(above two changes) still only one chance to verify
> > page fault numbers equality, because if "page_fault_num_1 !=
> > page_fault_num_2"
>
> Why "one chance"? With above we should get 50 chances.
>
> > it will keep looping until get the last page be checked. so that a bad
> > situation, it will usleep(100000) * 50 at most.
> >
> > In other words, the last page determines the test result though the bug
> > has been detected by previous pages.
>
> Problem is we don't know if it's a bug, pending I/O (after short delay)
> or kernel ignoring request for any other reason, as mentioned in madvise(2):
> "The kernel is free to ignore the advice.".
>
> My impression was that kernel bug was consistently reproducible,
> if not then let's replace the loop with one bigger sleep.
Sorry, I remember it's not, from what I test on an bad (unfix) kernel.
it always report PASS with this patch.
# ./madvise06
madvise06.c:57: INFO: dst_max = 7
madvise06.c:98: INFO: PageFault(no madvice): 8
madvise06.c:108: INFO: PageFault(madvice / no mem access): 8
madvise06.c:112: INFO: PageFault(madvice / mem access): 9
madvise06.c:108: INFO: PageFault(madvice / no mem access): 9
madvise06.c:112: INFO: PageFault(madvice / mem access): 10
madvise06.c:108: INFO: PageFault(madvice / no mem access): 10
madvise06.c:112: INFO: PageFault(madvice / mem access): 10
madvise06.c:137: PASS: Regression test pass
Summary:
passed 1
failed 0
skipped 0
warnings 0
Let's image the possible situations:
1. It's a bug. test fail on comparing the page fults many times and
keep looping to test but easily break out of the loop if one time
randomly PASS.
2, It pending I/O with short dely. Test pass soon(probably 2~3 times loop)
and break out of the loop with report PASS.
3. It caused by kernel ignoring the request for unknow reasons, fail in
50 times also and report PASS/BUG(I didn't catch the situation, so I
do know what result will be reported).
Obviously, the patch did not fit for the first situation. :(
Regards,
Li Wang
next prev parent reply other threads:[~2016-07-19 8:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-18 13:37 [LTP] [PATCH] madvise06: wait a bit after madvise() call Jan Stancek
2016-07-18 14:03 ` Cyril Hrubis
2016-07-18 14:22 ` Jan Stancek
2016-07-18 14:49 ` Cyril Hrubis
2016-07-19 5:58 ` Li Wang
2016-07-19 6:56 ` Jan Stancek
2016-07-19 8:57 ` Li Wang [this message]
2016-07-20 14:37 ` Jan Stancek
2016-07-21 5:33 ` Li Wang
2016-07-21 10:31 ` Chunyu Hu
2016-07-21 11:02 ` Li Wang
2016-07-21 14:23 ` Jan Stancek
2016-07-22 3:46 ` Li Wang
2016-07-22 6:59 ` Jan Stancek
2016-07-22 10:49 ` Chunyu Hu
2016-07-22 10:54 ` Chunyu Hu
2016-07-22 11:02 ` Jan Stancek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160719085756.GB31704@gmail.com \
--to=liwang@redhat.com \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox