[lkml]   [2017]   [Jul]   [27]   [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
On Wed 26-07-17 10:39:30, Mike Kravetz wrote:
> 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 <>
> >>> Signed-off-by: Mike Kravetz <>
> >>
> >>
> >> Acked-by: Michal Hocko <>
> >
> > 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_*. :(

Ups, and I completely missed that.

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

Why cannot we use a generic header? Btw. I think it would be better for
MMAP definitions as well.

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

Doesn't the respective call return -EINVAL on the unsupported hugepage

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

yes I think this makes more sense.
Michal Hocko

 \ /
  Last update: 2017-07-27 09:51    [W:0.086 / U:17.260 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site