On Thu, 2016-09-08 at 07:48 -0600, Kani, Toshimitsu wrote:
On Thu, 2016-09-08 at 13:57 +0300, Kirill A. Shutemov wrote:
> On Mon, Aug 29, 2016 at 10:00:43PM +0000, Kani, Toshimitsu wrote:
> > Looking further, these shmem_huge handlings only check pre-
> > conditions. So, we should be able to make shmem_get_unmapped_are
> > a() as a wrapper, which checks such shmem-specific conitions, and
> > then call __thp_get_unmapped_area() for the actual work. All
> > DAX-specific checks are performed in thp_get_unmapped_area() as
> > well. We can make __thp_get_unmapped_area() as a common
> > function.
> > I'd prefer to make such change as a separate item,
> Do you have plan to submit such change?
Yes, I will submit the change once I finish testing.
I found a bug in the current code, and need some clarification. The
if-statement below is reverted.
diff --git a/mm/shmem.c b/mm/shmem.c
index fd8b2b5..aec5b49 100644
@@ -1980,7 +1980,7 @@ unsigned long shmem_get_unmapped_area(struct file
sb = shm_mnt->mnt_sb;
- if (SHMEM_SB(sb)->huge != SHMEM_HUGE_NEVER)
+ if (SHMEM_SB(sb)->huge == SHMEM_HUGE_NEVER)
Because of this bug, mounting tmpfs with "huge=never" enables huge page
mappings, and "huge=always" or others disables it...
The above simple change will change the default behavior, though. When
"huge=" option is not specified, SHMEM_SB(sb)->huge is set to zero,
which is SHMEM_HUGE_NEVER. Therefore, huge page mappings are enabled
by default because of this bug.
What's the intended default behavior of this feature?