From: Li Wang <liwang@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 3/6] syscalls/madvise03: Convert to new test API
Date: Thu, 19 May 2016 18:12:42 +0800 [thread overview]
Message-ID: <20160519101242.GA20088@gmail.com> (raw)
In-Reply-To: <20160517162054.GC13705@rei.suse.cz>
Hi Cyril,
On Tue, May 17, 2016 at 06:20:55PM +0200, Cyril Hrubis wrote:
> > + /* (1) Test case for MADV_REMOVE */
> > + TEST(madvise(addr1, 4096, MADV_REMOVE));
> > + check_and_print("MADV_REMOVE");
>
> You don't need the shm memory for MADV_REMOVE, just mapping mapped
> PROT_WRITE as well.
There are different ways to support this on different kernels. If
just mapping mmapped as 'RW' shared memory, it will not work on
kernel < 3.5. It seems like we have to keep the orignal method which
based on shmfs.
From Linux Programmer's Manual:
"MADV_REMOVE (since Linux 2.6.16)
Free up a given range of pages and its associated backing
store. This is equivalent to punching a hole in the
corresponding byte range of the backing store (see
fallocate(2)). Subsequent accesses in the specified address
range will see bytes containing zero.
The specified address range must be mapped shared and
writable. This flag cannot be applied to locked pages, Huge
TLB pages, or VM_PFNMAP pages.
In the initial implementation, only shmfs/tmpfs supported
MADV_REMOVE; but since Linux 3.5, any filesystem which
supports the fallocate(2) FALLOC_FL_PUNCH_HOLE mode also
supports MADV_REMOVE. Hugetlbfs will fail with the error
EINVAL and other filesystems fail with the error EOPNOTSUPP."
A simple way is to create the mmaped file under '/dev/shm/' in setup()
sprintf(filename, "/dev/shm/madvise01.%d", getpid());
and remove it in cleanup(). Or using tmpfs.
What do you think?
Regards,
Li Wang
>
>
> --
> Cyril Hrubis
> chrubis@suse.cz
next prev parent reply other threads:[~2016-05-19 10:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-12 8:49 [LTP] [PATCH 1/6] syscalls/madvise01: Convert to new test API Li Wang
2016-05-12 8:49 ` [LTP] [PATCH 2/6] syscalls/madvise02: " Li Wang
2016-05-12 8:49 ` [LTP] [PATCH 3/6] syscalls/madvise03: " Li Wang
2016-05-12 8:49 ` [LTP] [PATCH 4/6] syscalls/madvise04: " Li Wang
2016-05-12 8:49 ` [LTP] [PATCH 5/6] syscalls/madvise05: " Li Wang
2016-05-12 8:49 ` [LTP] [PATCH 6/6] syscalls/madvise06: " Li Wang
2016-05-17 17:43 ` [LTP] [PATCH 5/6] syscalls/madvise05: " Cyril Hrubis
2016-05-17 17:28 ` [LTP] [PATCH 4/6] syscalls/madvise04: " Cyril Hrubis
2016-05-17 16:20 ` [LTP] [PATCH 3/6] syscalls/madvise03: " Cyril Hrubis
2016-05-18 9:04 ` Li Wang
2016-05-19 10:12 ` Li Wang [this message]
2016-05-19 10:19 ` Cyril Hrubis
2016-05-17 15:54 ` [LTP] [PATCH 2/6] syscalls/madvise02: " Cyril Hrubis
2016-05-17 15:21 ` [LTP] [PATCH 1/6] syscalls/madvise01: " Cyril Hrubis
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=20160519101242.GA20088@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