From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> To: Dave Hansen <dave@sr71.net> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, Andrea Arcangeli <aarcange@redhat.com>, Andrew Morton <akpm@linux-foundation.org>, Al Viro <viro@zeniv.linux.org.uk>, Hugh Dickins <hughd@google.com>, Wu Fengguang <fengguang.wu@intel.com>, Jan Kara <jack@suse.cz>, Mel Gorman <mgorman@suse.de>, linux-mm@kvack.org, Andi Kleen <ak@linux.intel.com>, Matthew Wilcox <matthew.r.wilcox@intel.com>, "Kirill A. Shutemov" <kirill@shutemov.name>, Hillf Danton <dhillf@gmail.com>, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RESEND] IOZone with transparent huge page cache Date: Tue, 16 Apr 2013 08:57:21 +0300 (EEST) [thread overview] Message-ID: <20130416055721.B8415E0085@blue.fi.intel.com> (raw) In-Reply-To: <516C8B03.7040203@sr71.net> Dave Hansen wrote: > On 04/15/2013 11:17 AM, Kirill A. Shutemov wrote: > > I run iozone using mmap files (-B) with different number of threads. > > The test machine is 4s Westmere - 4x10 cores + HT. > > How did you run this, exactly? Which iozone arguments? iozone -B -s 21822226/$threads -t $threads -r 4 -i 0 -i 1 -i 2 -i 3 It's slightly modified iozone test from mmtests. > It was run on ramfs, since that's the only thing that transparent huge page > cache supports right now? Correct. > > ** Initial writers ** > > threads: 1 2 4 8 16 32 64 128 256 > > baseline: 1103360 912585 500065 260503 128918 62039 34799 18718 9376 > > patched: 2127476 2155029 2345079 1942158 1127109 571899 127090 52939 25950 > > speed-up(times): 1.93 2.36 4.69 7.46 8.74 9.22 3.65 2.83 2.77 > > I'm a _bit_ surprised that iozone scales _that_ badly especially while > threads<nr_cpus. Is this normal for iozone? What are the units and > metric there, btw? The units is KB/sec per process (I used 'Avg throughput per process' from iozone report). So it scales not that badly. I will use total children throughput next time to avoid confusion. > > Minimal speed up is in 1-thread reverse readers - 23%. > > Maximal is 9.2 times in 32-thread initial writers. It's probably due > > batched radix tree insert - we insert 512 pages a time. It reduces > > mapping->tree_lock contention. > > It might actually be interesting to see this at 10, 20, 40, 80, etc... > since that'll actually match iozone threads to CPU cores on your > particular system. Okay. -- Kirill A. Shutemov
WARNING: multiple messages have this Message-ID (diff)
From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> To: Dave Hansen <dave@sr71.net> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, Andrea Arcangeli <aarcange@redhat.com>, Andrew Morton <akpm@linux-foundation.org>, Al Viro <viro@zeniv.linux.org.uk>, Hugh Dickins <hughd@google.com>, Wu Fengguang <fengguang.wu@intel.com>, Jan Kara <jack@suse.cz>, Mel Gorman <mgorman@suse.de>, linux-mm@kvack.org, Andi Kleen <ak@linux.intel.com>, Matthew Wilcox <matthew.r.wilcox@intel.com>, "Kirill A. Shutemov" <kirill@shutemov.name>, Hillf Danton <dhillf@gmail.com>, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RESEND] IOZone with transparent huge page cache Date: Tue, 16 Apr 2013 08:57:21 +0300 (EEST) [thread overview] Message-ID: <20130416055721.B8415E0085@blue.fi.intel.com> (raw) In-Reply-To: <516C8B03.7040203@sr71.net> Dave Hansen wrote: > On 04/15/2013 11:17 AM, Kirill A. Shutemov wrote: > > I run iozone using mmap files (-B) with different number of threads. > > The test machine is 4s Westmere - 4x10 cores + HT. > > How did you run this, exactly? Which iozone arguments? iozone -B -s 21822226/$threads -t $threads -r 4 -i 0 -i 1 -i 2 -i 3 It's slightly modified iozone test from mmtests. > It was run on ramfs, since that's the only thing that transparent huge page > cache supports right now? Correct. > > ** Initial writers ** > > threads: 1 2 4 8 16 32 64 128 256 > > baseline: 1103360 912585 500065 260503 128918 62039 34799 18718 9376 > > patched: 2127476 2155029 2345079 1942158 1127109 571899 127090 52939 25950 > > speed-up(times): 1.93 2.36 4.69 7.46 8.74 9.22 3.65 2.83 2.77 > > I'm a _bit_ surprised that iozone scales _that_ badly especially while > threads<nr_cpus. Is this normal for iozone? What are the units and > metric there, btw? The units is KB/sec per process (I used 'Avg throughput per process' from iozone report). So it scales not that badly. I will use total children throughput next time to avoid confusion. > > Minimal speed up is in 1-thread reverse readers - 23%. > > Maximal is 9.2 times in 32-thread initial writers. It's probably due > > batched radix tree insert - we insert 512 pages a time. It reduces > > mapping->tree_lock contention. > > It might actually be interesting to see this at 10, 20, 40, 80, etc... > since that'll actually match iozone threads to CPU cores on your > particular system. Okay. -- Kirill A. Shutemov -- 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>
next prev parent reply other threads:[~2013-04-16 5:55 UTC|newest] Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-04-05 11:59 [PATCHv3, RFC 00/34] Transparent huge page cache Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 01/34] mm: drop actor argument of do_generic_file_read() Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 02/34] block: implement add_bdi_stat() Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 03/34] mm: implement zero_huge_user_segment and friends Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 04/34] radix-tree: implement preload for multiple contiguous elements Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 05/34] memcg, thp: charge huge cache pages Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 06/34] thp, mm: avoid PageUnevictable on active/inactive lru lists Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 07/34] thp, mm: basic defines for transparent huge page cache Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 08/34] thp, mm: introduce mapping_can_have_hugepages() predicate Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 09/34] thp: represent file thp pages in meminfo and friends Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-08 19:38 ` Dave Hansen 2013-04-08 19:38 ` Dave Hansen 2013-04-16 14:49 ` Kirill A. Shutemov 2013-04-16 14:49 ` Kirill A. Shutemov 2013-04-16 15:11 ` Dave Hansen 2013-04-16 15:11 ` Dave Hansen 2013-04-05 11:59 ` [PATCHv3, RFC 10/34] thp, mm: rewrite add_to_page_cache_locked() to support huge pages Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 11/34] mm: trace filemap: dump page order Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 12/34] thp, mm: rewrite delete_from_page_cache() to support huge pages Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 13/34] thp, mm: trigger bug in replace_page_cache_page() on THP Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 14/34] thp, mm: locking tail page is a bug Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 15/34] thp, mm: handle tail pages in page_cache_get_speculative() Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 16/34] thp, mm: add event counters for huge page alloc on write to a file Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 17/34] thp, mm: implement grab_thp_write_begin() Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 18/34] thp, mm: naive support of thp in generic read/write routines Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 19/34] thp, libfs: initial support of thp in simple_read/write_begin/write_end Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 20/34] thp: handle file pages in split_huge_page() Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 21/34] thp: wait_split_huge_page(): serialize over i_mmap_mutex too Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 22/34] thp, mm: truncate support for transparent huge page cache Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 23/34] thp, mm: split huge page on mmap file page Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 24/34] ramfs: enable transparent huge page cache Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 25/34] x86-64, mm: proper alignment mappings with hugepages Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 26/34] mm: add huge_fault() callback to vm_operations_struct Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 27/34] thp: prepare zap_huge_pmd() to uncharge file pages Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 28/34] thp: move maybe_pmd_mkwrite() out of mk_huge_pmd() Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 29/34] thp, mm: basic huge_fault implementation for generic_file_vm_ops Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 30/34] thp: extract fallback path from do_huge_pmd_anonymous_page() to a function Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 31/34] thp: initial implementation of do_huge_linear_fault() Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-08 18:46 ` Dave Hansen 2013-04-08 18:46 ` Dave Hansen 2013-04-08 18:52 ` Dave Hansen 2013-04-08 18:52 ` Dave Hansen 2013-04-17 14:38 ` Kirill A. Shutemov 2013-04-17 14:38 ` Kirill A. Shutemov 2013-04-17 22:07 ` Dave Hansen 2013-04-18 16:09 ` Kirill A. Shutemov 2013-04-18 16:09 ` Kirill A. Shutemov 2013-04-18 16:19 ` Kirill A. Shutemov 2013-04-18 16:19 ` Kirill A. Shutemov 2013-04-18 16:19 ` Kirill A. Shutemov 2013-04-18 16:20 ` Dave Hansen 2013-04-18 16:20 ` Dave Hansen 2013-04-18 16:38 ` Kirill A. Shutemov 2013-04-18 16:38 ` Kirill A. Shutemov 2013-04-18 16:42 ` Dave Hansen 2013-04-18 16:42 ` Dave Hansen 2013-04-05 11:59 ` [PATCHv3, RFC 32/34] thp: handle write-protect exception to file-backed huge pages Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-08 19:07 ` Dave Hansen 2013-04-08 19:07 ` Dave Hansen 2013-04-26 15:31 ` Kirill A. Shutemov 2013-04-26 15:31 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 33/34] thp: call __vma_adjust_trans_huge() for file-backed VMA Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-05 11:59 ` [PATCHv3, RFC 34/34] thp: map file-backed huge pages on fault Kirill A. Shutemov 2013-04-05 11:59 ` Kirill A. Shutemov 2013-04-07 0:40 ` [PATCHv3, RFC 00/34] Transparent huge page cache Ric Mason 2013-04-07 0:40 ` Ric Mason 2013-04-15 16:02 ` IOZone with transparent " Kirill A. Shutemov 2013-04-15 16:02 ` Kirill A. Shutemov 2013-04-15 18:17 ` [RESEND] " Kirill A. Shutemov 2013-04-15 18:17 ` Kirill A. Shutemov 2013-04-15 23:19 ` Dave Hansen 2013-04-15 23:19 ` Dave Hansen 2013-04-16 5:57 ` Kirill A. Shutemov [this message] 2013-04-16 5:57 ` Kirill A. Shutemov 2013-04-16 6:11 ` Dave Hansen 2013-04-16 6:11 ` Dave Hansen
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=20130416055721.B8415E0085@blue.fi.intel.com \ --to=kirill.shutemov@linux.intel.com \ --cc=aarcange@redhat.com \ --cc=ak@linux.intel.com \ --cc=akpm@linux-foundation.org \ --cc=dave@sr71.net \ --cc=dhillf@gmail.com \ --cc=fengguang.wu@intel.com \ --cc=hughd@google.com \ --cc=jack@suse.cz \ --cc=kirill@shutemov.name \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=matthew.r.wilcox@intel.com \ --cc=mgorman@suse.de \ --cc=viro@zeniv.linux.org.uk \ /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: linkBe 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.