public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
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

  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