From: Ryan Roberts <ryan.roberts@arm.com>
To: Yin Fengwei <fengwei.yin@intel.com>, Yu Zhao <yuzhao@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <willy@infradead.org>,
David Hildenbrand <david@redhat.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Yang Shi <shy828301@gmail.com>,
"Huang, Ying" <ying.huang@intel.com>, Zi Yan <ziy@nvidia.com>,
Luis Chamberlain <mcgrof@kernel.org>,
Itaru Kitayama <itaru.kitayama@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 2/5] mm: LARGE_ANON_FOLIO for improved performance
Date: Thu, 3 Aug 2023 09:21:13 +0100 [thread overview]
Message-ID: <49142e18-fd4e-6487-113a-3112b1c17dbe@arm.com> (raw)
In-Reply-To: <4ae53b2a-e069-f579-428d-ac6f744cd19a@intel.com>
On 03/08/2023 09:05, Yin Fengwei wrote:
...
>> I've captured run time and peak memory usage, and taken the mean. The stdev for
>> the peak memory usage is big-ish, but I'm confident this still captures the
>> central tendancy well:
>>
>> | MAX_ORDER_UNHINTED | real-time | kern-time | user-time | peak memory |
>> |:-------------------|------------:|------------:|------------:|:------------|
>> | 4k | 0.0% | 0.0% | 0.0% | 0.0% |
>> | 16k | -3.6% | -26.5% | -0.5% | -0.1% |
>> | 32k | -4.8% | -37.4% | -0.6% | -0.1% |
>> | 64k | -5.7% | -42.0% | -0.6% | -1.1% |
>> | 128k | -5.6% | -42.1% | -0.7% | 1.4% |
>> | 256k | -4.9% | -41.9% | -0.4% | 1.9% |
>
> Here is my test result:
>
> real user sys
> hink-4k: 0% 0% 0%
> hink-16K: -3% 0.1% -18.3%
> hink-32K: -4% 0.2% -27.2%
> hink-64K: -4% 0.5% -31.0%
> hink-128K: -4% 0.9% -33.7%
> hink-256K: -5% 1% -34.6%
>
>
> I used command:
> /usr/bin/time -f "\t%E real,\t%U user,\t%S sys" make -skj96 allmodconfig all
> to build kernel and collect the real time/user time/kernel time.
> /sys/kernel/mm/transparent_hugepage/enabled is "madvise".
> Let me know if you have any question about the test.
Thanks for doing this! I have a couple of questions:
- how many times did you run each test?
- how did you configure the large page size? (I sent an email out yesterday
saying that I was doing it wrong from my tests, so the 128k and 256k results
for my test set are not valid.
- what does "hink" mean??
>
> I also find one strange behavior with this version. It's related with why
> I need to set the /sys/kernel/mm/transparent_hugepage/enabled to "madvise".
> If it's "never", the large folio is disabled either.
> If it's "always", the THP will be active before large folio. So the system is
> in the mixed mode. it's not suitable for this test.
We had a discussion around this in the THP meeting yesterday. I'm going to write
this up propoerly so we can have proper systematic discussion. The tentative
conclusion is that MADV_NOHUGEPAGE must continue to mean "do not fault in more
than is absolutely necessary". I would assume we need to extend that thinking to
the process-wide and system-wide knobs (as is done in the patch), but we didn't
explicitly say so in the meeting.
My intention is that if you have requested THP and your vma is big enough for
PMD-size then you get that, else you fallback to large anon folios. And if you
have neither opted in nor out, then you get large anon folios.
We talked about the idea of adding a new knob that let's you set the max order,
but that needs a lot more thought.
Anyway, as I said, I'll write it up so we can all systematically discuss.
>
> So if it's "never", large folio is disabled. But why "madvise" enables large
> folio unconditionly? Suppose it's only enabled for the VMA range which user
> madvise large folio (or THP)?
>
> Specific for the hink setting, my understand is that we can't choose it only
> by this testing. Other workloads may have different behavior with differnt
> hink setting.
>
>
> Regards
> Yin, Fengwei
>
next prev parent reply other threads:[~2023-08-03 8:21 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-26 9:51 [PATCH v4 0/5] variable-order, large folios for anonymous memory Ryan Roberts
2023-07-26 9:51 ` [PATCH v4 1/5] mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap() Ryan Roberts
2023-07-26 9:51 ` [PATCH v4 2/5] mm: LARGE_ANON_FOLIO for improved performance Ryan Roberts
2023-07-26 16:41 ` Yu Zhao
2023-07-27 4:31 ` Yu Zhao
2023-07-28 10:13 ` Ryan Roberts
2023-08-01 6:36 ` Yu Zhao
2023-08-01 23:30 ` Yin Fengwei
2023-08-02 8:02 ` Ryan Roberts
2023-08-02 9:04 ` Ryan Roberts
2023-08-02 13:51 ` Yin, Fengwei
2023-08-03 8:05 ` Yin Fengwei
2023-08-03 8:21 ` Ryan Roberts [this message]
2023-08-03 8:37 ` Yin Fengwei
2023-08-03 9:32 ` Ryan Roberts
2023-08-03 9:58 ` Yin Fengwei
2023-08-03 10:27 ` Ryan Roberts
2023-08-03 10:54 ` Yin Fengwei
2023-08-04 0:28 ` Yu Zhao
2023-08-01 6:18 ` Yu Zhao
2023-08-02 9:33 ` Ryan Roberts
2023-08-02 21:05 ` Yu Zhao
2023-08-03 10:24 ` Ryan Roberts
2023-08-03 12:43 ` Ryan Roberts
2023-08-03 14:21 ` Kirill A. Shutemov
2023-08-04 0:19 ` Yu Zhao
2023-08-04 2:16 ` Zi Yan
2023-08-04 3:35 ` Yu Zhao
2023-08-04 9:06 ` Ryan Roberts
2023-08-04 18:53 ` Yu Zhao
2023-08-07 19:00 ` Ryan Roberts
2023-08-03 23:50 ` Yu Zhao
2023-08-04 8:27 ` Ryan Roberts
2023-08-04 20:23 ` David Hildenbrand
2023-08-04 21:00 ` Yu Zhao
2023-08-04 21:13 ` David Hildenbrand
2023-08-04 21:26 ` Yu Zhao
2023-08-04 21:30 ` David Hildenbrand
2023-08-04 21:58 ` Zi Yan
2023-08-05 2:50 ` Yin, Fengwei
2023-08-07 17:45 ` Ryan Roberts
2023-08-07 18:10 ` Zi Yan
2023-08-08 9:58 ` Ryan Roberts
2023-08-07 5:24 ` Yu Zhao
2023-08-07 19:07 ` Ryan Roberts
2023-08-07 23:21 ` Yu Zhao
2023-08-08 9:37 ` Ryan Roberts
2023-08-08 17:57 ` Yu Zhao
2023-08-08 18:12 ` Yu Zhao
2023-08-09 16:08 ` Ryan Roberts
2023-07-26 9:51 ` [PATCH v4 3/5] arm64: mm: Override arch_wants_pte_order() Ryan Roberts
2023-07-26 9:51 ` [PATCH v4 4/5] selftests/mm/cow: Generalize do_run_with_thp() helper Ryan Roberts
2023-07-26 9:51 ` [PATCH v4 5/5] selftests/mm/cow: Add large anon folio tests Ryan Roberts
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=49142e18-fd4e-6487-113a-3112b1c17dbe@arm.com \
--to=ryan.roberts@arm.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=catalin.marinas@arm.com \
--cc=david@redhat.com \
--cc=fengwei.yin@intel.com \
--cc=itaru.kitayama@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mcgrof@kernel.org \
--cc=shy828301@gmail.com \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=ying.huang@intel.com \
--cc=yuzhao@google.com \
--cc=ziy@nvidia.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox