Re: [PATCH 1/3] hugetlbfs: Allow the creation of files suitable for MAP_PRIVATE on the vfs internal mount V3

Re: [PATCH 1/3] hugetlbfs: Allow the creation of files suitable for MAP_PRIVATE on the vfs internal mount V3

[David Rientjes]

On Fri, 14 Aug 2009, Eric B Munson wrote:

> There are two means of creating mappings backed by huge pages:
> 
>         1. mmap() a file created on hugetlbfs
>         2. Use shm which creates a file on an internal mount which essentially
>            maps it MAP_SHARED
> 
> The internal mount is only used for shared mappings but there is very
> little that stops it being used for private mappings. This patch extends
> hugetlbfs_file_setup() to deal with the creation of files that will be
> mapped MAP_PRIVATE on the internal hugetlbfs mount. This extended API is
> used in a subsequent patch to implement the MAP_HUGETLB mmap() flag.
> 
> Signed-off-by: Eric Munson <ebmunson@us.ibm.com>
> ---
> Changes from V2:
>  Rebase to newest linux-2.6 tree
>  Use base 10 value for HUGETLB_SHMFS_INODE instead of hex
> 
> Changes from V1:
>  Rebase to newest linux-2.6 tree
> 
>  fs/hugetlbfs/inode.c    |   22 ++++++++++++++++++----
>  include/linux/hugetlb.h |   10 +++++++++-
>  ipc/shm.c               |    3 ++-
>  3 files changed, 29 insertions(+), 6 deletions(-)
> 
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index 941c842..361f536 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -506,6 +506,13 @@ static struct inode *hugetlbfs_get_inode(struct super_block *sb, uid_t uid,
>  		inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME;
>  		INIT_LIST_HEAD(&inode->i_mapping->private_list);
>  		info = HUGETLBFS_I(inode);
> +		/*
> +		 * The policy is initialized here even if we are creating a
> +		 * private inode because initialization simply creates an
> +		 * an empty rb tree and calls spin_lock_init(), later when we
> +		 * call mpol_free_shared_policy() it will just return because
> +		 * the rb tree will still be empty.
> +		 */
>  		mpol_shared_policy_init(&info->policy, NULL);
>  		switch (mode & S_IFMT) {
>  		default:
> @@ -930,12 +937,19 @@ static struct file_system_type hugetlbfs_fs_type = {
>  
>  static struct vfsmount *hugetlbfs_vfsmount;
>  
> -static int can_do_hugetlb_shm(void)
> +static int can_do_hugetlb_shm(int creat_flags)
>  {
> -	return capable(CAP_IPC_LOCK) || in_group_p(sysctl_hugetlb_shm_group);
> +	if (!(creat_flags & HUGETLB_SHMFS_INODE))
> +		return 0;

That should be

	if (creat_flags != HUGETLB_SHMFS_INODE)
		return 0;

Re: [PATCH 3/3] Add MAP_HUGETLB example V3

[David Rientjes]

On Fri, 14 Aug 2009, Eric B Munson wrote:

> This patch adds an example of how to use the MAP_HUGETLB flag to the
> vm documentation directory and a reference to the example in
> hugetlbpage.txt.
> 
> Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>

Acked-by: David Rientjes <rientjes@google.com>

Adding Randy Dunlap to the cc.


> ---
> Changes from V2:
>  Rebase to newest linux-2.6 tree
>  Fix comment in example referencing MAP_LARGEPAGE
>  Move example code to its own file
>  Update hugetlbpage.txt with MAP_HUGETLB information and example reference
>  Add map_hugetlb.c to 00-INDEX
> 
> Changes from V1:
>  Rebase to newest linux-2.6 tree
>  Change MAP_LARGEPAGE to MAP_HUGETLB to match flag name in huge page shm
> 
>  Documentation/vm/00-INDEX        |    2 +
>  Documentation/vm/hugetlbpage.txt |   14 ++++---
>  Documentation/vm/map_hugetlb.c   |   77 ++++++++++++++++++++++++++++++++++++++
>  3 files changed, 87 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/vm/map_hugetlb.c
> 
> diff --git a/Documentation/vm/00-INDEX b/Documentation/vm/00-INDEX
> index 2f77ced..aabd973 100644
> --- a/Documentation/vm/00-INDEX
> +++ b/Documentation/vm/00-INDEX
> @@ -20,3 +20,5 @@ slabinfo.c
>  	- source code for a tool to get reports about slabs.
>  slub.txt
>  	- a short users guide for SLUB.
> +map_hugetlb.c
> +	- an example program that uses the MAP_HUGETLB mmap flag.
> diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt
> index ea8714f..6a8feab 100644
> --- a/Documentation/vm/hugetlbpage.txt
> +++ b/Documentation/vm/hugetlbpage.txt
> @@ -146,12 +146,14 @@ Regular chown, chgrp, and chmod commands (with right permissions) could be
>  used to change the file attributes on hugetlbfs.
>  
>  Also, it is important to note that no such mount command is required if the
> -applications are going to use only shmat/shmget system calls.  Users who
> -wish to use hugetlb page via shared memory segment should be a member of
> -a supplementary group and system admin needs to configure that gid into
> -/proc/sys/vm/hugetlb_shm_group.  It is possible for same or different
> -applications to use any combination of mmaps and shm* calls, though the
> -mount of filesystem will be required for using mmap calls.
> +applications are going to use only shmat/shmget system calls or mmap with
> +MAP_HUGETLB.  Users who wish to use hugetlb page via shared memory segment
> +should be a member of a supplementary group and system admin needs to
> +configure that gid into /proc/sys/vm/hugetlb_shm_group.  It is possible for
> +same or different applications to use any combination of mmaps and shm*
> +calls, though the mount of filesystem will be required for using mmap calls
> +without MAP_HUGETLB.  For an example of how to use mmap with MAP_HUGETLB see
> +map_hugetlb.c.
>  
>  *******************************************************************
>  
> diff --git a/Documentation/vm/map_hugetlb.c b/Documentation/vm/map_hugetlb.c
> new file mode 100644
> index 0000000..e2bdae3
> --- /dev/null
> +++ b/Documentation/vm/map_hugetlb.c
> @@ -0,0 +1,77 @@
> +/*
> + * Example of using hugepage memory in a user application using the mmap
> + * system call with MAP_HUGETLB flag.  Before running this program make
> + * sure the administrator has allocated enough default sized huge pages
> + * to cover the 256 MB allocation.
> + *
> + * For ia64 architecture, Linux kernel reserves Region number 4 for hugepages.
> + * That means the addresses starting with 0x800000... will need to be
> + * specified.  Specifying a fixed address is not required on ppc64, i386
> + * or x86_64.
> + */
> +#include <stdlib.h>
> +#include <stdio.h>
> +#include <unistd.h>
> +#include <sys/mman.h>
> +#include <fcntl.h>
> +
> +#define LENGTH (256UL*1024*1024)
> +#define PROTECTION (PROT_READ | PROT_WRITE)
> +
> +#ifndef MAP_HUGETLB
> +#define MAP_HUGETLB 0x40
> +#endif
> +
> +/* Only ia64 requires this */
> +#ifdef __ia64__
> +#define ADDR (void *)(0x8000000000000000UL)
> +#define FLAGS (MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB | MAP_FIXED)
> +#else
> +#define ADDR (void *)(0x0UL)
> +#define FLAGS (MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB)
> +#endif
> +
> +void check_bytes(char *addr)
> +{
> +	printf("First hex is %x\n", *((unsigned int *)addr));
> +}
> +
> +void write_bytes(char *addr)
> +{
> +	unsigned long i;
> +
> +	for (i = 0; i < LENGTH; i++)
> +		*(addr + i) = (char)i;
> +}
> +
> +void read_bytes(char *addr)
> +{
> +	unsigned long i;
> +
> +	check_bytes(addr);
> +	for (i = 0; i < LENGTH; i++)
> +		if (*(addr + i) != (char)i) {
> +			printf("Mismatch at %lu\n", i);
> +			break;
> +		}
> +}
> +
> +int main(void)
> +{
> +	void *addr;
> +
> +	addr = mmap(ADDR, LENGTH, PROTECTION, FLAGS, 0, 0);
> +	if (addr == MAP_FAILED) {
> +		perror("mmap");
> +		exit(1);
> +	}
> +
> +	printf("Returned address is %p\n", addr);
> +	check_bytes(addr);
> +	write_bytes(addr);
> +	read_bytes(addr);
> +
> +	munmap(addr, LENGTH);
> +
> +	return 0;
> +}
> -- 
> 1.6.3.2
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
> 

Re: [PATCH 0/3] Add pseudo-anonymous huge page mappings V3

[Andi Kleen]

Eric B Munson <ebmunson@us.ibm.com> writes:

> This patch set adds a flag to mmap that allows the user to request
> a mapping to be backed with huge pages.  This mapping will borrow
> functionality from the huge page shm code to create a file on the
> kernel internal mount and uses it to approximate an anonymous
> mapping.  The MAP_HUGETLB flag is a modifier to MAP_ANONYMOUS
> and will not work without both flags being preset.


You seem to have forgotten to describe WHY you want this?

>From my guess, this seems to be another step into turning hugetlb.c
into another parallel VM implementation. Instead of basically
developing two parallel VMs wouldn't it be better to unify the two?

I think extending hugetlb.c forever without ever thinking about
that is not the right approach.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.