lkml.org 
[lkml]   [2020]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe [PATCH] [RFC]hugetlbfs: Get unmapped area below TASK_UNMAPPED_BASE for hugetlbfs
Date
 On 4/28/20 6:46 AM, Mike Kravetz wrote:
>Just curious. Have you actually seeing a problem with this code, or is
>the reason for the proposed change just the result of code inspection? I ask
>because many architectures have their own version of hugetlb_get_unmapped_area.
>So, if you are seeing this issue it would be interesting to know what
>architecture you are running.

Thanks for your reply.

We actually found this problem on arm64 architecture, running a 32-bit
program. When the address space below TASK_UNMAPPED_BASE is completely
exhausted, shmat() for huge pages will return ENOMEM, but shmat() for
normal pages can still success.

>The routine hugetlb_get_unmapped_area has not changed much since this first
>git version. I suspect this is because it is mostly unused.
>
>I noticed that hugetlb_get_unmapped_area is one of only a few places in arch
>independent code calling vm_unmapped_area(). The other callers are arch
>independent fall back routines for arch_get_unmapped_area* routines. If we
>move forward with changes to this routine, would it make more sense to use
>the arch_get_unmapped_area* routines instead of calling vm_unmapped_area
>directly? This would take advantage of any arch specific if it exists.

I totally agree with you.

It is more appropriate to implementing hugetlb_get_unmapped_area() for a
specific architecture, instead of chaging common hugetlb_get_unmapped_area()
interface at "fs/hugetlbfs/inode.c".

I will submit another patch just for specific architectures (arm64) later.
Thanks for your reply and advise.
\
 
 \ /
  Last update: 2020-04-28 13:50    [W:0.029 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site