All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shi, Yang" <yang.shi@linaro.org>
To: Jerome Marchand <jmarchan@redhat.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Hugh Dickins <hughd@google.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Hansen <dave.hansen@intel.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Christoph Lameter <cl@gentwo.org>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	Sasha Levin <sasha.levin@oracle.com>,
	Andres Lagar-Cavilla <andreslc@google.com>,
	Ning Qu <quning@gmail.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCHv7 00/29] THP-enabled tmpfs/shmem using compound pages
Date: Tue, 19 Apr 2016 09:11:55 -0700	[thread overview]
Message-ID: <571658CB.9080205@linaro.org> (raw)
In-Reply-To: <571641AC.1050801@redhat.com>

On 4/19/2016 7:33 AM, Jerome Marchand wrote:
> On 04/19/2016 12:55 AM, Shi, Yang wrote:
>> 2. I ran my THP test (generated a program with 4MB text section) on both
>> x86-64 and ARM64 with yours and Hugh's patches (linux-next tree), I got
>> the program execution time reduced by ~12% on x86-64, it looks very
>> impressive.
>>
>> But, on ARM64, there is just ~3% change, and sometimes huge tmpfs may
>> show even worse data than non-hugepage.
>>
>> Both yours and Hugh's patches has the same behavior.
>>
>> Any idea?
>
> Just a shot in the dark, but what page size do you use? If you use 4k
> pages, then hugepage size should be the same as on x86 and a similar

I do use 4K pages for both x86-64 and ARM64 in my testing.

Thanks,
Yang

> behavior could be expected. Otherwise, hugepages would be too big to be
> taken advantage of by your test program.
>
> Jerome
>

WARNING: multiple messages have this Message-ID (diff)
From: "Shi, Yang" <yang.shi@linaro.org>
To: Jerome Marchand <jmarchan@redhat.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Hugh Dickins <hughd@google.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Hansen <dave.hansen@intel.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Christoph Lameter <cl@gentwo.org>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	Sasha Levin <sasha.levin@oracle.com>,
	Andres Lagar-Cavilla <andreslc@google.com>,
	Ning Qu <quning@gmail.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCHv7 00/29] THP-enabled tmpfs/shmem using compound pages
Date: Tue, 19 Apr 2016 09:11:55 -0700	[thread overview]
Message-ID: <571658CB.9080205@linaro.org> (raw)
In-Reply-To: <571641AC.1050801@redhat.com>

On 4/19/2016 7:33 AM, Jerome Marchand wrote:
> On 04/19/2016 12:55 AM, Shi, Yang wrote:
>> 2. I ran my THP test (generated a program with 4MB text section) on both
>> x86-64 and ARM64 with yours and Hugh's patches (linux-next tree), I got
>> the program execution time reduced by ~12% on x86-64, it looks very
>> impressive.
>>
>> But, on ARM64, there is just ~3% change, and sometimes huge tmpfs may
>> show even worse data than non-hugepage.
>>
>> Both yours and Hugh's patches has the same behavior.
>>
>> Any idea?
>
> Just a shot in the dark, but what page size do you use? If you use 4k
> pages, then hugepage size should be the same as on x86 and a similar

I do use 4K pages for both x86-64 and ARM64 in my testing.

Thanks,
Yang

> behavior could be expected. Otherwise, hugepages would be too big to be
> taken advantage of by your test program.
>
> Jerome
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-04-19 16:11 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-16  0:23 [PATCHv7 00/29] THP-enabled tmpfs/shmem using compound pages Kirill A. Shutemov
2016-04-16  0:23 ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 01/29] thp, mlock: update unevictable-lru.txt Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 02/29] mm: do not pass mm_struct into handle_mm_fault Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 03/29] mm: introduce fault_env Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 04/29] mm: postpone page table allocation until we have page to map Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 05/29] rmap: support file thp Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 06/29] mm: introduce do_set_pmd() Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 07/29] thp, vmstats: add counters for huge file pages Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 08/29] thp: support file pages in zap_huge_pmd() Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 09/29] thp: handle file pages in split_huge_pmd() Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 10/29] thp: handle file COW faults Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 11/29] thp: skip file huge pmd on copy_huge_pmd() Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 12/29] thp: prepare change_huge_pmd() for file thp Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 13/29] thp: run vma_adjust_trans_huge() outside i_mmap_rwsem Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 14/29] thp: file pages support for split_huge_page() Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 15/29] thp, mlock: do not mlock PTE-mapped file huge pages Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 16/29] vmscan: split file huge pages before paging them out Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 17/29] page-flags: relax policy for PG_mappedtodisk and PG_reclaim Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 18/29] radix-tree: implement radix_tree_maybe_preload_order() Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 19/29] filemap: prepare find and delete operations for huge pages Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 20/29] truncate: handle file thp Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 21/29] mm, rmap: account shmem thp pages Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 22/29] shmem: prepare huge= mount option and sysfs knob Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 23/29] shmem: get_unmapped_area align huge page Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 24/29] shmem: add huge pages support Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 25/29] shmem, thp: respect MADV_{NO,}HUGEPAGE for file mappings Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 26/29] thp: update Documentation/vm/transhuge.txt Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 27/29] thp: extract khugepaged from mm/huge_memory.c Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:23 ` [PATCHv7 28/29] khugepaged: move up_read(mmap_sem) out of khugepaged_alloc_page() Kirill A. Shutemov
2016-04-16  0:23   ` Kirill A. Shutemov
2016-04-16  0:24 ` [PATCHv7 29/29] khugepaged: add support of collapse for tmpfs/shmem pages Kirill A. Shutemov
2016-04-16  0:24   ` Kirill A. Shutemov
2016-04-18 22:55 ` [PATCHv7 00/29] THP-enabled tmpfs/shmem using compound pages Shi, Yang
2016-04-18 22:55   ` Shi, Yang
2016-04-19 14:33   ` Jerome Marchand
2016-04-19 16:11     ` Shi, Yang [this message]
2016-04-19 16:11       ` Shi, Yang
2016-04-19 16:50   ` Andrea Arcangeli
2016-04-19 16:50     ` Andrea Arcangeli
2016-04-19 17:07     ` Andres Lagar-Cavilla
2016-04-19 17:07       ` Andres Lagar-Cavilla
2016-04-24  5:46       ` Wincy Van
2016-04-24  5:46         ` Wincy Van
2016-04-25 13:30         ` Andres Lagar-Cavilla
2016-04-25 13:30           ` Andres Lagar-Cavilla
2016-04-26 14:02           ` Wincy Van
2016-04-26 14:02             ` Wincy Van
2016-04-27 15:48       ` Andrea Arcangeli
2016-04-27 15:48         ` Andrea Arcangeli
2016-04-19 23:48     ` Shi, Yang
2016-04-19 23:48       ` Shi, Yang
2016-04-20  8:31   ` Hugh Dickins
2016-04-20  8:31     ` Hugh Dickins
2016-04-20  8:31     ` Hugh Dickins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=571658CB.9080205@linaro.org \
    --to=yang.shi@linaro.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreslc@google.com \
    --cc=cl@gentwo.org \
    --cc=dave.hansen@intel.com \
    --cc=hughd@google.com \
    --cc=jmarchan@redhat.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=quning@gmail.com \
    --cc=sasha.levin@oracle.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.