On Mon, 2016-08-29 at 23:48 +0300, Kirill A. Shutemov wrote: > On Mon, Aug 29, 2016 at 01:11:19PM -0600, Toshi Kani wrote: > > > > When CONFIG_FS_DAX_PMD is set, DAX supports mmap() using pmd page > > size. This feature relies on both mmap virtual address and FS > > block (i.e. physical address) to be aligned by the pmd page size. > > Users can use mkfs options to specify FS to align block > > allocations. However, aligning mmap address requires code changes > > to existing applications for providing a pmd-aligned address to > > mmap(). > > > > For instance, fio with "ioengine=mmap" performs I/Os with mmap() > > [1]. It calls mmap() with a NULL address, which needs to be changed > > to provide a pmd-aligned address for testing with DAX pmd mappings. > > Changing all applications that call mmap() with NULL is > > undesirable. > > > > This patch-set extends filesystems to align an mmap address for > > a DAX file so that unmodified applications can use DAX pmd > > mappings. > > +Hugh > > Can we get it used for shmem/tmpfs too? > I don't think we should duplicate essentially the same functionality > in multiple places. Here is my brief analysis when I had looked at the Hugh's patch last time (before shmem_get_unmapped_area() was accepted). https://patchwork.kernel.org/patch/8916741/ Besides some differences in the logic, ex. shmem_get_unmapped_area() always calls current->mm->get_unmapped_area twice, yes, they basically provide the same functionality. I think one issue is that shmem_get_unmapped_area() checks with its static flag 'shmem_huge', and additinally deals with SHMEM_HUGE_DENY and SHMEM_HUGE_FORCE cases. It also handles non-file case for !SHMEM_HUGE_FORCE. Thanks, -Toshi ��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
