linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH] fs: introduce ST_HUGE flag and set it to tmpfs and hugetlbfs
@ 2018-04-17 21:08 Yang Shi
  2018-04-17 21:31 ` Andrew Morton
                   ` (3 more replies)
  0 siblings, 4 replies; 13+ messages in thread
From: Yang Shi @ 2018-04-17 21:08 UTC (permalink / raw)
  To: viro, nyc, mike.kravetz, kirill.shutemov, hughd, akpm
  Cc: yang.shi, linux-fsdevel, linux-mm, linux-kernel

Since tmpfs THP was supported in 4.8, hugetlbfs is not the only
filesystem with huge page support anymore. tmpfs can use huge page via
THP when mounting by "huge=" mount option.

When applications use huge page on hugetlbfs, it just need check the
filesystem magic number, but it is not enough for tmpfs. So, introduce
ST_HUGE flag to statfs if super block has SB_HUGE set which indicates
huge page is supported on the specific filesystem.

Some applications could benefit from this change, for example QEMU.
When use mmap file as guest VM backend memory, QEMU typically mmap the
file size plus one extra page. If the file is on hugetlbfs the extra
page is huge page size (i.e. 2MB), but it is still 4KB on tmpfs even
though THP is enabled. tmpfs THP requires VMA is huge page aligned, so
if 4KB page is used THP will not be used at all. The below /proc/meminfo
fragment shows the THP use of QEMU with 4K page:

ShmemHugePages:   679936 kB
ShmemPmdMapped:        0 kB

With ST_HUGE flag, QEMU can get huge page, then /proc/meminfo looks
like:

ShmemHugePages:    77824 kB
ShmemPmdMapped:     6144 kB

With this flag, the applications can know if huge page is supported on
the filesystem then optimize the behavior of the applications
accordingly. Although the similar function can be implemented in
applications by traversing the mount options, it looks more convenient
if kernel can provide such flag.

Even though ST_HUGE is set, f_bsize still returns 4KB for tmpfs since
THP could be split, and it also my fallback to 4KB page silently if
there is not enough huge page.

And, set the flag for hugetlbfs as well to keep the consistency, and the
applications don't have to know what filesystem is used to use huge
page, just need to check ST_HUGE flag.

Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Nadia Yvette Chambers <nyc@holomorphy.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Hugh Dickins <hughd@google.com>
---
 fs/hugetlbfs/inode.c   | 1 +
 fs/statfs.c            | 2 ++
 include/linux/fs.h     | 1 +
 include/linux/statfs.h | 1 +
 mm/shmem.c             | 8 ++++++++
 5 files changed, 13 insertions(+)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index b9a254d..3754b45 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -1265,6 +1265,7 @@ static void init_once(void *foo)
 	sb->s_op = &hugetlbfs_ops;
 	sb->s_time_gran = 1;
 	sb->s_root = d_make_root(hugetlbfs_get_root(sb, &config));
+	sb->s_flags |= SB_HUGE;
 	if (!sb->s_root)
 		goto out_free;
 	return 0;
diff --git a/fs/statfs.c b/fs/statfs.c
index 5b2a24f..ac0403a 100644
--- a/fs/statfs.c
+++ b/fs/statfs.c
@@ -41,6 +41,8 @@ static int flags_by_sb(int s_flags)
 		flags |= ST_MANDLOCK;
 	if (s_flags & SB_RDONLY)
 		flags |= ST_RDONLY;
+	if (s_flags & SB_HUGE)
+		flags |= ST_HUGE;
 	return flags;
 }
 
diff --git a/include/linux/fs.h b/include/linux/fs.h
index c6baf76..df246e9 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1287,6 +1287,7 @@ struct fasync_struct {
 #define SB_SYNCHRONOUS	16	/* Writes are synced at once */
 #define SB_MANDLOCK	64	/* Allow mandatory locks on an FS */
 #define SB_DIRSYNC	128	/* Directory modifications are synchronous */
+#define SB_HUGE		256	/* Support hugepage/THP */
 #define SB_NOATIME	1024	/* Do not update access times. */
 #define SB_NODIRATIME	2048	/* Do not update directory access times */
 #define SB_SILENT	32768
diff --git a/include/linux/statfs.h b/include/linux/statfs.h
index 3142e98..79a634b 100644
--- a/include/linux/statfs.h
+++ b/include/linux/statfs.h
@@ -40,5 +40,6 @@ struct kstatfs {
 #define ST_NOATIME	0x0400	/* do not update access times */
 #define ST_NODIRATIME	0x0800	/* do not update directory access times */
 #define ST_RELATIME	0x1000	/* update atime relative to mtime/ctime */
+#define ST_HUGE		0x2000	/* support hugepage/thp */
 
 #endif
diff --git a/mm/shmem.c b/mm/shmem.c
index b859192..d5312ec 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -3632,6 +3632,11 @@ static int shmem_remount_fs(struct super_block *sb, int *flags, char *data)
 	sbinfo->max_inodes  = config.max_inodes;
 	sbinfo->free_inodes = config.max_inodes - inodes;
 
+	if (sbinfo->huge > 0)
+		sb->s_flags |= SB_HUGE;
+	else
+		sb->s_flags &= ~SB_HUGE;
+
 	/*
 	 * Preserve previous mempolicy unless mpol remount option was specified.
 	 */
@@ -3804,6 +3809,9 @@ int shmem_fill_super(struct super_block *sb, void *data, int silent)
 	}
 	sb->s_export_op = &shmem_export_ops;
 	sb->s_flags |= SB_NOSEC;
+
+	if (sbinfo->huge > 0)
+		sb->s_flags |= SB_HUGE;
 #else
 	sb->s_flags |= SB_NOUSER;
 #endif
-- 
1.8.3.1

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [RFC PATCH] fs: introduce ST_HUGE flag and set it to tmpfs and hugetlbfs
  2018-04-17 21:08 [RFC PATCH] fs: introduce ST_HUGE flag and set it to tmpfs and hugetlbfs Yang Shi
@ 2018-04-17 21:31 ` Andrew Morton
  2018-04-17 21:51   ` Yang Shi
  2018-04-17 23:22 ` Matthew Wilcox
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 13+ messages in thread
From: Andrew Morton @ 2018-04-17 21:31 UTC (permalink / raw)
  To: Yang Shi
  Cc: viro, nyc, mike.kravetz, kirill.shutemov, hughd, linux-fsdevel,
	linux-mm, linux-kernel

On Wed, 18 Apr 2018 05:08:13 +0800 Yang Shi <yang.shi@linux.alibaba.com> wrote:

> Since tmpfs THP was supported in 4.8, hugetlbfs is not the only
> filesystem with huge page support anymore. tmpfs can use huge page via
> THP when mounting by "huge=" mount option.
> 
> When applications use huge page on hugetlbfs, it just need check the
> filesystem magic number, but it is not enough for tmpfs. So, introduce
> ST_HUGE flag to statfs if super block has SB_HUGE set which indicates
> huge page is supported on the specific filesystem.
> 
> Some applications could benefit from this change, for example QEMU.
> When use mmap file as guest VM backend memory, QEMU typically mmap the
> file size plus one extra page. If the file is on hugetlbfs the extra
> page is huge page size (i.e. 2MB), but it is still 4KB on tmpfs even
> though THP is enabled. tmpfs THP requires VMA is huge page aligned, so
> if 4KB page is used THP will not be used at all. The below /proc/meminfo
> fragment shows the THP use of QEMU with 4K page:
> 
> ShmemHugePages:   679936 kB
> ShmemPmdMapped:        0 kB
> 
> With ST_HUGE flag, QEMU can get huge page, then /proc/meminfo looks
> like:
> 
> ShmemHugePages:    77824 kB
> ShmemPmdMapped:     6144 kB
> 
> With this flag, the applications can know if huge page is supported on
> the filesystem then optimize the behavior of the applications
> accordingly. Although the similar function can be implemented in
> applications by traversing the mount options, it looks more convenient
> if kernel can provide such flag.
> 
> Even though ST_HUGE is set, f_bsize still returns 4KB for tmpfs since
> THP could be split, and it also my fallback to 4KB page silently if
> there is not enough huge page.
> 
> And, set the flag for hugetlbfs as well to keep the consistency, and the
> applications don't have to know what filesystem is used to use huge
> page, just need to check ST_HUGE flag.
> 

Patch is simple enough, although I'm having trouble forming an opinion
about it ;)

It will call for an update to the statfs(2) manpage.  I'm not sure
which of linux-man@vger.kernel.org, mtk.manpages@gmail.com and
linux-api@vger.kernel.org is best for that, so I'd cc all three...

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC PATCH] fs: introduce ST_HUGE flag and set it to tmpfs and hugetlbfs
  2018-04-17 21:31 ` Andrew Morton
@ 2018-04-17 21:51   ` Yang Shi
  0 siblings, 0 replies; 13+ messages in thread
From: Yang Shi @ 2018-04-17 21:51 UTC (permalink / raw)
  To: Andrew Morton
  Cc: viro, nyc, mike.kravetz, kirill.shutemov, hughd, linux-fsdevel,
	linux-mm, linux-kernel, linux-man, mtk.manpages, linux-api



On 4/17/18 2:31 PM, Andrew Morton wrote:
> On Wed, 18 Apr 2018 05:08:13 +0800 Yang Shi <yang.shi@linux.alibaba.com> wrote:
>
>> Since tmpfs THP was supported in 4.8, hugetlbfs is not the only
>> filesystem with huge page support anymore. tmpfs can use huge page via
>> THP when mounting by "huge=" mount option.
>>
>> When applications use huge page on hugetlbfs, it just need check the
>> filesystem magic number, but it is not enough for tmpfs. So, introduce
>> ST_HUGE flag to statfs if super block has SB_HUGE set which indicates
>> huge page is supported on the specific filesystem.
>>
>> Some applications could benefit from this change, for example QEMU.
>> When use mmap file as guest VM backend memory, QEMU typically mmap the
>> file size plus one extra page. If the file is on hugetlbfs the extra
>> page is huge page size (i.e. 2MB), but it is still 4KB on tmpfs even
>> though THP is enabled. tmpfs THP requires VMA is huge page aligned, so
>> if 4KB page is used THP will not be used at all. The below /proc/meminfo
>> fragment shows the THP use of QEMU with 4K page:
>>
>> ShmemHugePages:   679936 kB
>> ShmemPmdMapped:        0 kB
>>
>> With ST_HUGE flag, QEMU can get huge page, then /proc/meminfo looks
>> like:
>>
>> ShmemHugePages:    77824 kB
>> ShmemPmdMapped:     6144 kB
>>
>> With this flag, the applications can know if huge page is supported on
>> the filesystem then optimize the behavior of the applications
>> accordingly. Although the similar function can be implemented in
>> applications by traversing the mount options, it looks more convenient
>> if kernel can provide such flag.
>>
>> Even though ST_HUGE is set, f_bsize still returns 4KB for tmpfs since
>> THP could be split, and it also my fallback to 4KB page silently if
>> there is not enough huge page.
>>
>> And, set the flag for hugetlbfs as well to keep the consistency, and the
>> applications don't have to know what filesystem is used to use huge
>> page, just need to check ST_HUGE flag.
>>
> Patch is simple enough, although I'm having trouble forming an opinion
> about it ;)
>
> It will call for an update to the statfs(2) manpage.  I'm not sure
> which of linux-man@vger.kernel.org, mtk.manpages@gmail.com and
> linux-api@vger.kernel.org is best for that, so I'd cc all three...

Thanks, Andrew. Added cc to those 3 lists.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC PATCH] fs: introduce ST_HUGE flag and set it to tmpfs and hugetlbfs
  2018-04-17 21:08 [RFC PATCH] fs: introduce ST_HUGE flag and set it to tmpfs and hugetlbfs Yang Shi
  2018-04-17 21:31 ` Andrew Morton
@ 2018-04-17 23:22 ` Matthew Wilcox
  2018-04-17 23:37   ` Yang Shi
  2018-04-18 10:27 ` Christoph Hellwig
  2018-04-18 20:26 ` Mike Kravetz
  3 siblings, 1 reply; 13+ messages in thread
From: Matthew Wilcox @ 2018-04-17 23:22 UTC (permalink / raw)
  To: Yang Shi
  Cc: viro, nyc, mike.kravetz, kirill.shutemov, hughd, akpm,
	linux-fsdevel, linux-mm, linux-kernel

On Wed, Apr 18, 2018 at 05:08:13AM +0800, Yang Shi wrote:
> When applications use huge page on hugetlbfs, it just need check the
> filesystem magic number, but it is not enough for tmpfs. So, introduce
> ST_HUGE flag to statfs if super block has SB_HUGE set which indicates
> huge page is supported on the specific filesystem.

Hm.  What's the plan for communicating support for page sizes other
than PMD page sizes?  I know ARM has several different page sizes,
as do PA-RISC and ia64.  Even x86 might support 1G page sizes through
tmpfs one day.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC PATCH] fs: introduce ST_HUGE flag and set it to tmpfs and hugetlbfs
  2018-04-17 23:22 ` Matthew Wilcox
@ 2018-04-17 23:37   ` Yang Shi
  0 siblings, 0 replies; 13+ messages in thread
From: Yang Shi @ 2018-04-17 23:37 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: viro, nyc, mike.kravetz, kirill.shutemov, hughd, akpm,
	linux-fsdevel, linux-mm, linux-kernel



On 4/17/18 4:22 PM, Matthew Wilcox wrote:
> On Wed, Apr 18, 2018 at 05:08:13AM +0800, Yang Shi wrote:
>> When applications use huge page on hugetlbfs, it just need check the
>> filesystem magic number, but it is not enough for tmpfs. So, introduce
>> ST_HUGE flag to statfs if super block has SB_HUGE set which indicates
>> huge page is supported on the specific filesystem.
> Hm.  What's the plan for communicating support for page sizes other
> than PMD page sizes?  I know ARM has several different page sizes,
> as do PA-RISC and ia64.  Even x86 might support 1G page sizes through
> tmpfs one day.

For THP page size, we already have 
/sys/kernel/mm/transparent_hugepage/hpage_pmd_size exported. The 
applications could read this to get the THP size. If PUD size THP 
supported is added later, we can export hpage_pud_size.

Please see the below commit log for more details:

commit 49920d28781dcced10cd30cb9a938e7d045a1c94
Author: Hugh Dickins <hughd@google.com>
Date:   Mon Dec 12 16:44:50 2016 -0800

     mm: make transparent hugepage size public

     Test programs want to know the size of a transparent hugepage. While it
     is commonly the same as the size of a hugetlbfs page (shown as
     Hugepagesize in /proc/meminfo), that is not always so: powerpc
     implements transparent hugepages in a different way from hugetlbfs
     pages, so it's coincidence when their sizes are the same; and x86 and
     others can support more than one hugetlbfs page size.

     Add /sys/kernel/mm/transparent_hugepage/hpage_pmd_size to show the THP
     size in bytes - it's the same for Anonymous and Shmem hugepages.  Call
     it hpage_pmd_size (after HPAGE_PMD_SIZE) rather than hpage_size, in 
case
     some transparent support for pud and pgd pages is added later.


Thanks,
Yang

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC PATCH] fs: introduce ST_HUGE flag and set it to tmpfs and hugetlbfs
  2018-04-17 21:08 [RFC PATCH] fs: introduce ST_HUGE flag and set it to tmpfs and hugetlbfs Yang Shi
  2018-04-17 21:31 ` Andrew Morton
  2018-04-17 23:22 ` Matthew Wilcox
@ 2018-04-18 10:27 ` Christoph Hellwig
  2018-04-18 18:18   ` Yang Shi
  2018-04-18 20:26 ` Mike Kravetz
  3 siblings, 1 reply; 13+ messages in thread
From: Christoph Hellwig @ 2018-04-18 10:27 UTC (permalink / raw)
  To: Yang Shi
  Cc: viro, nyc, mike.kravetz, kirill.shutemov, hughd, akpm,
	linux-fsdevel, linux-mm, linux-kernel

On Wed, Apr 18, 2018 at 05:08:13AM +0800, Yang Shi wrote:
> Since tmpfs THP was supported in 4.8, hugetlbfs is not the only
> filesystem with huge page support anymore. tmpfs can use huge page via
> THP when mounting by "huge=" mount option.
> 
> When applications use huge page on hugetlbfs, it just need check the
> filesystem magic number, but it is not enough for tmpfs. So, introduce
> ST_HUGE flag to statfs if super block has SB_HUGE set which indicates
> huge page is supported on the specific filesystem.
> 
> Some applications could benefit from this change, for example QEMU.
> When use mmap file as guest VM backend memory, QEMU typically mmap the
> file size plus one extra page. If the file is on hugetlbfs the extra
> page is huge page size (i.e. 2MB), but it is still 4KB on tmpfs even
> though THP is enabled. tmpfs THP requires VMA is huge page aligned, so
> if 4KB page is used THP will not be used at all. The below /proc/meminfo
> fragment shows the THP use of QEMU with 4K page:
> 
> ShmemHugePages:   679936 kB
> ShmemPmdMapped:        0 kB
> 
> With ST_HUGE flag, QEMU can get huge page, then /proc/meminfo looks
> like:
> 
> ShmemHugePages:    77824 kB
> ShmemPmdMapped:     6144 kB
> 
> With this flag, the applications can know if huge page is supported on
> the filesystem then optimize the behavior of the applications
> accordingly. Although the similar function can be implemented in
> applications by traversing the mount options, it looks more convenient
> if kernel can provide such flag.
> 
> Even though ST_HUGE is set, f_bsize still returns 4KB for tmpfs since
> THP could be split, and it also my fallback to 4KB page silently if
> there is not enough huge page.

Seems like your should report it through the st_blksize field of struct
stat then, instead of introducing a not very useful binary field then.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC PATCH] fs: introduce ST_HUGE flag and set it to tmpfs and hugetlbfs
  2018-04-18 10:27 ` Christoph Hellwig
@ 2018-04-18 18:18   ` Yang Shi
  2018-04-19  8:28     ` Christoph Hellwig
  0 siblings, 1 reply; 13+ messages in thread
From: Yang Shi @ 2018-04-18 18:18 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: viro, nyc, mike.kravetz, kirill.shutemov, hughd, akpm,
	linux-fsdevel, linux-mm, linux-kernel



On 4/18/18 3:27 AM, Christoph Hellwig wrote:
> On Wed, Apr 18, 2018 at 05:08:13AM +0800, Yang Shi wrote:
>> Since tmpfs THP was supported in 4.8, hugetlbfs is not the only
>> filesystem with huge page support anymore. tmpfs can use huge page via
>> THP when mounting by "huge=" mount option.
>>
>> When applications use huge page on hugetlbfs, it just need check the
>> filesystem magic number, but it is not enough for tmpfs. So, introduce
>> ST_HUGE flag to statfs if super block has SB_HUGE set which indicates
>> huge page is supported on the specific filesystem.
>>
>> Some applications could benefit from this change, for example QEMU.
>> When use mmap file as guest VM backend memory, QEMU typically mmap the
>> file size plus one extra page. If the file is on hugetlbfs the extra
>> page is huge page size (i.e. 2MB), but it is still 4KB on tmpfs even
>> though THP is enabled. tmpfs THP requires VMA is huge page aligned, so
>> if 4KB page is used THP will not be used at all. The below /proc/meminfo
>> fragment shows the THP use of QEMU with 4K page:
>>
>> ShmemHugePages:   679936 kB
>> ShmemPmdMapped:        0 kB
>>
>> With ST_HUGE flag, QEMU can get huge page, then /proc/meminfo looks
>> like:
>>
>> ShmemHugePages:    77824 kB
>> ShmemPmdMapped:     6144 kB
>>
>> With this flag, the applications can know if huge page is supported on
>> the filesystem then optimize the behavior of the applications
>> accordingly. Although the similar function can be implemented in
>> applications by traversing the mount options, it looks more convenient
>> if kernel can provide such flag.
>>
>> Even though ST_HUGE is set, f_bsize still returns 4KB for tmpfs since
>> THP could be split, and it also my fallback to 4KB page silently if
>> there is not enough huge page.
> Seems like your should report it through the st_blksize field of struct
> stat then, instead of introducing a not very useful binary field then.

Yes, thanks for the suggestion. I did think about it before I went with 
the new flag. Not like hugetlb, THP will *not* guarantee huge page is 
used all the time, it may fallback to regular 4K page or may get split. 
I'm not sure how the applications use f_bsize field, it might break 
existing applications and the value might be abused by applications to 
have counter optimization. So, IMHO, a new flag may sound safer.

Yang

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC PATCH] fs: introduce ST_HUGE flag and set it to tmpfs and hugetlbfs
  2018-04-17 21:08 [RFC PATCH] fs: introduce ST_HUGE flag and set it to tmpfs and hugetlbfs Yang Shi
                   ` (2 preceding siblings ...)
  2018-04-18 10:27 ` Christoph Hellwig
@ 2018-04-18 20:26 ` Mike Kravetz
  2018-04-18 20:53   ` Yang Shi
  2018-04-19  9:01   ` Kirill A. Shutemov
  3 siblings, 2 replies; 13+ messages in thread
From: Mike Kravetz @ 2018-04-18 20:26 UTC (permalink / raw)
  To: Yang Shi, viro, nyc, kirill.shutemov, hughd, akpm
  Cc: linux-fsdevel, linux-mm, linux-kernel

On 04/17/2018 02:08 PM, Yang Shi wrote:
> And, set the flag for hugetlbfs as well to keep the consistency, and the
> applications don't have to know what filesystem is used to use huge
> page, just need to check ST_HUGE flag.

For hugetlbfs, setting such a flag would be for consistency only.  mapping
hugetlbfs files REQUIRES huge page alignment and size.

If an application would want to take advantage of this flag for tmpfs, it
needs to map at a fixed address (MAP_FIXED) for huge page alignment.  So,
it will need to do one of the 'mmap tricks' to get a mapping at a suitably
aligned address.  

IIRC, there is code to 'suitably align' DAX mappings to appropriate huge page
boundaries.  Perhaps, something like this could be added for tmpfs mounted
with huge=?  Of course, this would not take into account 'length' but may
help some.

-- 
Mike Kravetz

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC PATCH] fs: introduce ST_HUGE flag and set it to tmpfs and hugetlbfs
  2018-04-18 20:26 ` Mike Kravetz
@ 2018-04-18 20:53   ` Yang Shi
  2018-04-19  9:01   ` Kirill A. Shutemov
  1 sibling, 0 replies; 13+ messages in thread
From: Yang Shi @ 2018-04-18 20:53 UTC (permalink / raw)
  To: Mike Kravetz, viro, nyc, kirill.shutemov, hughd, akpm
  Cc: linux-fsdevel, linux-mm, linux-kernel



On 4/18/18 1:26 PM, Mike Kravetz wrote:
> On 04/17/2018 02:08 PM, Yang Shi wrote:
>> And, set the flag for hugetlbfs as well to keep the consistency, and the
>> applications don't have to know what filesystem is used to use huge
>> page, just need to check ST_HUGE flag.
> For hugetlbfs, setting such a flag would be for consistency only.  mapping
> hugetlbfs files REQUIRES huge page alignment and size.

Yes, applications don't have to read this flag if the underlying 
filesystem is hugetlbfs. The fs magic number is good enough.

>
> If an application would want to take advantage of this flag for tmpfs, it
> needs to map at a fixed address (MAP_FIXED) for huge page alignment.  So,
> it will need to do one of the 'mmap tricks' to get a mapping at a suitably
> aligned address.

It doesn't have to be MAP_FIXED, but definitely has to be huge page 
aligned. This flag is aimed for this case. With this flag, the 
applications can know the underlying tmpfs with huge page supported, 
then the applications can mmap memory with huge page alignment 
intentionally.

>
> IIRC, there is code to 'suitably align' DAX mappings to appropriate huge page
> boundaries.  Perhaps, something like this could be added for tmpfs mounted
> with huge=?  Of course, this would not take into account 'length' but may
> help some.

Might be. However THP already exported huge page size to sysfs, the 
applications can read it to get the alignment.

Thanks,
Yang

>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC PATCH] fs: introduce ST_HUGE flag and set it to tmpfs and hugetlbfs
  2018-04-18 18:18   ` Yang Shi
@ 2018-04-19  8:28     ` Christoph Hellwig
  2018-04-19  9:05       ` Kirill A. Shutemov
  2018-04-20  0:18       ` Yang Shi
  0 siblings, 2 replies; 13+ messages in thread
From: Christoph Hellwig @ 2018-04-19  8:28 UTC (permalink / raw)
  To: Yang Shi
  Cc: Christoph Hellwig, viro, nyc, mike.kravetz, kirill.shutemov,
	hughd, akpm, linux-fsdevel, linux-mm, linux-kernel

On Wed, Apr 18, 2018 at 11:18:25AM -0700, Yang Shi wrote:
> Yes, thanks for the suggestion. I did think about it before I went with the
> new flag. Not like hugetlb, THP will *not* guarantee huge page is used all
> the time, it may fallback to regular 4K page or may get split. I'm not sure
> how the applications use f_bsize field, it might break existing applications
> and the value might be abused by applications to have counter optimization.
> So, IMHO, a new flag may sound safer.

But st_blksize isn't the block size, that is why I suggested it.  It is
the preferred I/O size, and various file systems can report way
larger values than the block size already.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC PATCH] fs: introduce ST_HUGE flag and set it to tmpfs and hugetlbfs
  2018-04-18 20:26 ` Mike Kravetz
  2018-04-18 20:53   ` Yang Shi
@ 2018-04-19  9:01   ` Kirill A. Shutemov
  1 sibling, 0 replies; 13+ messages in thread
From: Kirill A. Shutemov @ 2018-04-19  9:01 UTC (permalink / raw)
  To: Mike Kravetz
  Cc: Yang Shi, viro, nyc, kirill.shutemov, hughd, akpm, linux-fsdevel,
	linux-mm, linux-kernel

On Wed, Apr 18, 2018 at 01:26:35PM -0700, Mike Kravetz wrote:
> If an application would want to take advantage of this flag for tmpfs, it
> needs to map at a fixed address (MAP_FIXED) for huge page alignment.  So,
> it will need to do one of the 'mmap tricks' to get a mapping at a suitably
> aligned address.  

We don't need MAP_FIXED. We already have all required magic in
shmem_get_unmapped_area().

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC PATCH] fs: introduce ST_HUGE flag and set it to tmpfs and hugetlbfs
  2018-04-19  8:28     ` Christoph Hellwig
@ 2018-04-19  9:05       ` Kirill A. Shutemov
  2018-04-20  0:18       ` Yang Shi
  1 sibling, 0 replies; 13+ messages in thread
From: Kirill A. Shutemov @ 2018-04-19  9:05 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Yang Shi, viro, nyc, mike.kravetz, kirill.shutemov, hughd, akpm,
	linux-fsdevel, linux-mm, linux-kernel

On Thu, Apr 19, 2018 at 01:28:10AM -0700, Christoph Hellwig wrote:
> On Wed, Apr 18, 2018 at 11:18:25AM -0700, Yang Shi wrote:
> > Yes, thanks for the suggestion. I did think about it before I went with the
> > new flag. Not like hugetlb, THP will *not* guarantee huge page is used all
> > the time, it may fallback to regular 4K page or may get split. I'm not sure
> > how the applications use f_bsize field, it might break existing applications
> > and the value might be abused by applications to have counter optimization.
> > So, IMHO, a new flag may sound safer.
> 
> But st_blksize isn't the block size, that is why I suggested it.  It is
> the preferred I/O size, and various file systems can report way
> larger values than the block size already.

I agree. This looks like a better fit.

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [RFC PATCH] fs: introduce ST_HUGE flag and set it to tmpfs and hugetlbfs
  2018-04-19  8:28     ` Christoph Hellwig
  2018-04-19  9:05       ` Kirill A. Shutemov
@ 2018-04-20  0:18       ` Yang Shi
  1 sibling, 0 replies; 13+ messages in thread
From: Yang Shi @ 2018-04-20  0:18 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: viro, nyc, mike.kravetz, kirill.shutemov, hughd, akpm,
	linux-fsdevel, linux-mm, linux-kernel



On 4/19/18 1:28 AM, Christoph Hellwig wrote:
> On Wed, Apr 18, 2018 at 11:18:25AM -0700, Yang Shi wrote:
>> Yes, thanks for the suggestion. I did think about it before I went with the
>> new flag. Not like hugetlb, THP will *not* guarantee huge page is used all
>> the time, it may fallback to regular 4K page or may get split. I'm not sure
>> how the applications use f_bsize field, it might break existing applications
>> and the value might be abused by applications to have counter optimization.
>> So, IMHO, a new flag may sound safer.
> But st_blksize isn't the block size, that is why I suggested it.  It is
> the preferred I/O size, and various file systems can report way
> larger values than the block size already.

Thanks. If it is safe to applications, It definitely can return huge 
page size via st_blksize.

Is it safe to return huge page size via statfs->f_bsize? It sounds it 
has not to be the physical block size too. The man page says it is 
"Optimal transfer block size".

Yang

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2018-04-20  0:18 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-17 21:08 [RFC PATCH] fs: introduce ST_HUGE flag and set it to tmpfs and hugetlbfs Yang Shi
2018-04-17 21:31 ` Andrew Morton
2018-04-17 21:51   ` Yang Shi
2018-04-17 23:22 ` Matthew Wilcox
2018-04-17 23:37   ` Yang Shi
2018-04-18 10:27 ` Christoph Hellwig
2018-04-18 18:18   ` Yang Shi
2018-04-19  8:28     ` Christoph Hellwig
2018-04-19  9:05       ` Kirill A. Shutemov
2018-04-20  0:18       ` Yang Shi
2018-04-18 20:26 ` Mike Kravetz
2018-04-18 20:53   ` Yang Shi
2018-04-19  9:01   ` Kirill A. Shutemov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).