Re: [RFC PATCH 4/4] mm: madvise allow remove operation for hugetlbfs

Re: [RFC PATCH 4/4] mm: madvise allow remove operation for hugetlbfs

[Hillf Danton]

> 
> Now that we have hole punching support for hugetlbfs, we can
> also support the MADV_REMOVE interface to it.
> 
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
> ---
>  mm/madvise.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/madvise.c b/mm/madvise.c
> index d551475..c4a1027 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -299,7 +299,7 @@ static long madvise_remove(struct vm_area_struct *vma,
> 
>  	*prev = NULL;	/* tell sys_madvise we drop mmap_sem */
> 
> -	if (vma->vm_flags & (VM_LOCKED | VM_HUGETLB))
> +	if (vma->vm_flags & VM_LOCKED)
>  		return -EINVAL;
> 
>  	f = vma->vm_file;
> --
> 2.1.0

After the above change offset is computed,

	offset = (loff_t)(start - vma->vm_start)
		+ ((loff_t)vma->vm_pgoff << PAGE_SHIFT);

and I wonder if it is correct for huge page mapping.

Hillf

--
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: [RFC PATCH 4/4] mm: madvise allow remove operation for hugetlbfs

[Mike Kravetz]

On 04/17/2015 12:10 AM, Hillf Danton wrote:
>>
>> Now that we have hole punching support for hugetlbfs, we can
>> also support the MADV_REMOVE interface to it.
>>
>> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
>> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
>> ---
>>   mm/madvise.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/madvise.c b/mm/madvise.c
>> index d551475..c4a1027 100644
>> --- a/mm/madvise.c
>> +++ b/mm/madvise.c
>> @@ -299,7 +299,7 @@ static long madvise_remove(struct vm_area_struct *vma,
>>
>>   	*prev = NULL;	/* tell sys_madvise we drop mmap_sem */
>>
>> -	if (vma->vm_flags & (VM_LOCKED | VM_HUGETLB))
>> +	if (vma->vm_flags & VM_LOCKED)
>>   		return -EINVAL;
>>
>>   	f = vma->vm_file;
>> --
>> 2.1.0
>
> After the above change offset is computed,
>
> 	offset = (loff_t)(start - vma->vm_start)
> 		+ ((loff_t)vma->vm_pgoff << PAGE_SHIFT);
>
> and I wonder if it is correct for huge page mapping.

I think it will be correct.

The above will be a (base) page size aligned offset into the file.
This offset will be huge page aligned in the fallocate hole punch
code.

	/*
	 * For hole punch round up the beginning offset of the hole and
	 * round down the end.
	 */
	hole_start = (offset + hpage_size - 1) & ~huge_page_mask(h);
	hole_end = (offset + len - (hpage_size - 1)) * ~huge_page_mask(h);

Was the alignment your concern, or something else?
-- 
Mike Kravetz

--
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: [RFC PATCH 4/4] mm: madvise allow remove operation for hugetlbfs

[Mike Kravetz]

On 04/17/2015 10:11 AM, Mike Kravetz wrote:
> On 04/17/2015 12:10 AM, Hillf Danton wrote:
>>>
>>> Now that we have hole punching support for hugetlbfs, we can
>>> also support the MADV_REMOVE interface to it.
>>>
>>> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
>>> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
>>> ---
>>>   mm/madvise.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/mm/madvise.c b/mm/madvise.c
>>> index d551475..c4a1027 100644
>>> --- a/mm/madvise.c
>>> +++ b/mm/madvise.c
>>> @@ -299,7 +299,7 @@ static long madvise_remove(struct vm_area_struct
>>> *vma,
>>>
>>>       *prev = NULL;    /* tell sys_madvise we drop mmap_sem */
>>>
>>> -    if (vma->vm_flags & (VM_LOCKED | VM_HUGETLB))
>>> +    if (vma->vm_flags & VM_LOCKED)
>>>           return -EINVAL;
>>>
>>>       f = vma->vm_file;
>>> --
>>> 2.1.0
>>
>> After the above change offset is computed,
>>
>>     offset = (loff_t)(start - vma->vm_start)
>>         + ((loff_t)vma->vm_pgoff << PAGE_SHIFT);
>>
>> and I wonder if it is correct for huge page mapping.
>
> I think it will be correct.
>
> The above will be a (base) page size aligned offset into the file.
> This offset will be huge page aligned in the fallocate hole punch
> code.
>
>      /*
>       * For hole punch round up the beginning offset of the hole and
>       * round down the end.
>       */
>      hole_start = (offset + hpage_size - 1) & ~huge_page_mask(h);
>      hole_end = (offset + len - (hpage_size - 1)) * ~huge_page_mask(h);
>
> Was the alignment your concern, or something else?

Well, that alignment code in fallocate hole punch obviously wrong. :(
Sorry about that.  I'll send out an updated RFC with working hole punch.

-- 
Mike Kravetz

--
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>

[RFC PATCH 0/4] hugetlbfs: add fallocate support

[Mike Kravetz]

hugetlbfs is used today by applications that want a high degree of
control over huge page usage.  Often, large hugetlbfs files are used
to map a large number huge pages into the application processes.
The applications know when page ranges within these large files will
no longer be used, and ideally would like to release them back to
the subpool or global pools for other uses.  The fallocate() system
call provides an interface for preallocation and hole punching within
files.  This patch set adds fallocate functionality to hugetlbfs.

Mike Kravetz (4):
  hugetlbfs: truncate_hugepages() takes a range of pages
  hugetlbfs: New huge_add_to_page_cache helper routine
  hugetlbfs: add hugetlbfs_fallocate()
  mm: madvise allow remove operation for hugetlbfs

 fs/hugetlbfs/inode.c    | 164 ++++++++++++++++++++++++++++++++++++++++++++++--
 include/linux/hugetlb.h |   5 ++
 mm/hugetlb.c            |  29 ++++++---
 mm/madvise.c            |   2 +-
 4 files changed, 185 insertions(+), 15 deletions(-)

-- 
2.1.0

--
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>

[RFC PATCH 4/4] mm: madvise allow remove operation for hugetlbfs

[Mike Kravetz]

Now that we have hole punching support for hugetlbfs, we can
also support the MADV_REMOVE interface to it.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
---
 mm/madvise.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/madvise.c b/mm/madvise.c
index d551475..c4a1027 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -299,7 +299,7 @@ static long madvise_remove(struct vm_area_struct *vma,
 
 	*prev = NULL;	/* tell sys_madvise we drop mmap_sem */
 
-	if (vma->vm_flags & (VM_LOCKED | VM_HUGETLB))
+	if (vma->vm_flags & VM_LOCKED)
 		return -EINVAL;
 
 	f = vma->vm_file;
-- 
2.1.0

--
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: [RFC PATCH 4/4] mm: madvise allow remove operation for hugetlbfs

[Christoph Hellwig]

On Thu, Apr 16, 2015 at 04:02:58PM -0700, Mike Kravetz wrote:
> Now that we have hole punching support for hugetlbfs, we can
> also support the MADV_REMOVE interface to it.

Meh.  Just use fallocate for any new code..

--
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: [RFC PATCH 4/4] mm: madvise allow remove operation for hugetlbfs

[Mike Kravetz]

On 04/16/2015 11:44 PM, Christoph Hellwig wrote:
> On Thu, Apr 16, 2015 at 04:02:58PM -0700, Mike Kravetz wrote:
>> Now that we have hole punching support for hugetlbfs, we can
>> also support the MADV_REMOVE interface to it.
>
> Meh.  Just use fallocate for any new code..
>

I don't have the complete context for your comment.  Is there
a general consensus or effort underway to deprecate the use
of MADV_REMOVE?

-- 
Mike Kravetz

--
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>