lkml.org 
[lkml]   [2017]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH 3/3] mm: shm: Use new hugetlb size encoding definitions
From
Date
On 07/26/2017 03:07 AM, Michal Hocko wrote:
> On Wed 26-07-17 11:53:38, Michal Hocko wrote:
>> On Mon 17-07-17 15:28:01, Mike Kravetz wrote:
>>> Use the common definitions from hugetlb_encode.h header file for
>>> encoding hugetlb size definitions in shmget system call flags. In
>>> addition, move these definitions to the from the internal to user
>>> (uapi) header file.
>>
>> s@to the from@from@
>>
>>>
>>> Suggested-by: Matthew Wilcox <willy@infradead.org>
>>> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
>>
>> with s@HUGETLB_FLAG_ENCODE__16GB@HUGETLB_FLAG_ENCODE_16GB@
>>
>> Acked-by: Michal Hocko <mhocko@suse.com>
>
> Btw. man page mentions only 2MB and 1GB, we should document others and
> note that each arch might support only subset of them

Thanks for looking at these Michal.
BTW, those definitions below are wrong. They should be SHM_HUGE_*. :(

In the overview of this RFC, I mentioned still needing to address the
comment from Aneesh about splitting SHM_HUGE_* definitions into arch
specific header files. This is how it is done for mmap. If an arch
supports multiple huge page sizes, the 'asm/mman.h' contains definitions
for those sizes. There will be a bit of churn (such as header file
renaming) to do this for shm as well. So, I keep going back and forth
asking myself 'is it worth it'? Some things to consider.

- We should be consistent between mmap and shm. Also remember, that I
will propose adding the same type of encoding to memfd_create. So,
three system calls will use the encoding. They should be consistent.
- Adding the arch specific definitions seems the 'most correct', as a
user can not use a definition not supported by the arch. However,
even if an arch supports a huge page size it does not mean that the
running kernel supports that size. Therefore, the folllowing is in
the man page.
"The range of huge page sizes that are supported by the system
can be discovered by listing the subdirectories in
/sys/kernel/mm/hugepages."
- Another alternative is to make all known huge page sizes available
to all users. This is 'easier' as the definitions can likely reside
in a common header file. The user will need to determine what
huge page sizes are supported by the running kernel as mentioned in
the man page.

Any thoughts/suggestions on these alternatives? I'll send out another
patch set based on comments. In any case, I think mmap and shm need to
be the same.
--
Mike Kravetz

>>> +#define MAP_HUGE_512KB HUGETLB_FLAG_ENCODE_512KB
>>> +#define MAP_HUGE_1MB HUGETLB_FLAG_ENCODE_1MB
>>> +#define MAP_HUGE_2MB HUGETLB_FLAG_ENCODE_2MB
>>> +#define MAP_HUGE_8MB HUGETLB_FLAG_ENCODE_8MB
>>> +#define MAP_HUGE_16MB HUGETLB_FLAG_ENCODE_16MB
>>> +#define MAP_HUGE_1GB HUGETLB_FLAG_ENCODE_1GB
>>> +#define MAP_HUGE_16GB HUGETLB_FLAG_ENCODE__16GB

\
 
 \ /
  Last update: 2017-07-26 19:41    [W:0.252 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site