[LTP] [PATCH 3/6] syscalls/madvise03: Convert to new test API
Cyril Hrubis
chrubis@suse.cz
Thu May 19 12:19:08 CEST 2016
Hi!
> 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?
Or we may use the POSIX IPC instead of the System V one. And if we do
shm_open(), ftruncate(), mmap(), shm_unlink(), and close() in setup()
everything will be freed once the mapping is released which will happen
automatically when the test exits. Technically this is the same as
opening file in /dev/shm/ but I would rather use the shm_open() instead.
--
Cyril Hrubis
chrubis@suse.cz
More information about the ltp
mailing list