From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] madvise06: wait a bit after madvise() call
Date: Mon, 18 Jul 2016 10:22:13 -0400 (EDT) [thread overview]
Message-ID: <123467926.6065614.1468851733409.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20160718140319.GA19087@rei.suse.cz>
----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp@lists.linux.it, liwan@redhat.com
> Sent: Monday, 18 July, 2016 4:03:19 PM
> Subject: Re: [LTP] [PATCH] madvise06: wait a bit after madvise() call
>
> Hi!
> > madvise_willneed() only schedules I/O and does not
> > wait for completion, so there is possibility for this
> > testcase to fail occasionally.
> >
> > This patch is introducing a small delay and checks the
> > effect of madvise on more pages.
>
> Looks good.
>
> What is the reason for using more than one page? Does that increase the
> likehood of triggering the issue?
Because testcase faults in page by writing to it. After it does that, page
is present and subsequent loops would always give you PASS.
Multiple pages give you same starting state (page is swapped, currently
test assumes they are), if madvise loaded it from swap already (I/O caught up),
then write shouldn't change number of maj_faults.
>
> Another idea may be to utilize bitflags from /proc/self/pagemap which
> would be non-destructive way to get the present/swapped information.
That is what I meant by "Testcase doesn't check buf[0] is swapped". You
can check that page is swapped before calling madvise...
> Then we can do a short loop that polls these flags with much shorter
> sleep, but the code would likely end up more complicated than this...
... but that page won't be present after madvise call (I checked),
I'm assuming that's because madvise loads it only to page cache
(in same style as readahead).
Regards,
Jan
>
> --
> Cyril Hrubis
> chrubis@suse.cz
>
next prev parent reply other threads:[~2016-07-18 14:22 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 [this message]
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
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=123467926.6065614.1468851733409.JavaMail.zimbra@redhat.com \
--to=jstancek@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