From: Mike Kravetz <mike.kravetz@oracle.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Li Xinhai <lixinhai.lxh@gmail.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
akpm <akpm@linux-foundation.org>,
"yang.shi" <yang.shi@linux.alibaba.com>,
n-horiguchi <n-horiguchi@ah.jp.nec.com>
Subject: Re: [PATCH 2/2] mm/mempolicy: Skip walking HUGETLB vma if MPOL_MF_STRICT is specified alone
Date: Thu, 16 Jan 2020 11:22:51 -0800 [thread overview]
Message-ID: <b1b4a3b1-905f-8dd6-6be7-d55ad04401c2@oracle.com> (raw)
In-Reply-To: <20200116075933.GN19428@dhcp22.suse.cz>
On 1/15/20 11:59 PM, Michal Hocko wrote:
> On Wed 15-01-20 13:07:17, Mike Kravetz wrote:
>> What should we do?
>> ==================
>> 1) Nothing more than optimizations by Li Xinhai. Behavior that could be
>> seen as conflicting with man page has existed since v3.12 and I am
>> not aware of any complaints.
>> 2) In addition to optimizations by Li Xinhai, modify code to truly ignore
>> MPOL_MF_STRICT for huge page mappings. This would be fairly easy to do
>> after a failure of migrate_pages(). We could simply traverse the list
>> of pages that were not migrated looking for any non-hugetlb page.
>> 3) Remove the statement "MPOL_MF_STRICT is ignored on huge page mappings."
>> and modify code accordingly.
>>
>> My suggestion would be for 1 or 2. Thoughts?
>
> And why do we exactly need to do anything at all? There is an
> inconsistency that has been there for years without anybody noticing.
> NUMA API is a mess on its own and unfixable at this stage, there will
> always be some corner cases. If there is no real workload hitting this
> incosistency and suffering, I would rather not touch this at all.
> Unless the change would clean up the code or make it more maintainable.
That is a very valid point. Sometimes we as developers get focused on the
actual code changes and fail to ask the question "does this really need to
be changed?" or "what value do the code changes provide?".
Li Xinhai came up with two optimizations in how the mbind code deals with
hugetlb pages. This 'sub-optimal' code has existed for more than 6 years.
Unless I am mistaken, nobody has actually complained or noticed this behavior.
I believe Li Xinhai noticed this inefficient code via code inspection. Of
course, based on what we know today one could write a test program to show
the inefficient behavior. However, no real users have noticed this during
the past 6 years.
The proposed code changes are fairly simple. However, I would not say that
they clean up the code or make it more maintainable. They essentially add
or modify two checks to bail out early for hugetlb vma's if the flag which
is documented to not apply to hugetlb pages (MPOL_MF_STRICT) is specified.
If one is trying to follow the entire mbind code path for hugetlb pages,
these patches will make that easier follow/understand. That is simply
because one can ignore downstream code/functionality.
Based on Michal's criteria above, I now believe the code changes should not
be made. Yes, they are fairly simple. However, even simple changes have
the potential to break something (build breakage with v1 of patch). We should
leave this code as is unless issues are reported by users.
--
Mike Kravetz
next prev parent reply other threads:[~2020-01-16 19:23 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-14 9:16 [PATCH 1/2] mm/mempolicy: Checking hstate for hugetlbfs page in vma_migratable Li Xinhai
2020-01-14 9:16 ` [PATCH 2/2] mm/mempolicy: Skip walking HUGETLB vma if MPOL_MF_STRICT is specified alone Li Xinhai
2020-01-14 14:09 ` Li Xinhai
2020-01-14 18:27 ` Yang Shi
2020-01-15 1:07 ` Mike Kravetz
2020-01-15 1:24 ` Yang Shi
2020-01-15 4:28 ` Mike Kravetz
2020-01-15 5:23 ` Yang Shi
2020-01-15 7:36 ` Li Xinhai
2020-01-15 17:16 ` Yang Shi
2020-01-15 21:07 ` Mike Kravetz
2020-01-15 21:30 ` Yang Shi
2020-01-15 21:45 ` Mike Kravetz
2020-01-15 21:59 ` Yang Shi
2020-01-16 8:07 ` HORIGUCHI NAOYA(堀口 直也)
2020-01-16 15:32 ` Li Xinhai
2020-01-16 7:59 ` Michal Hocko
2020-01-16 19:22 ` Mike Kravetz [this message]
2020-01-17 2:32 ` Yang Shi
2020-01-17 2:38 ` Li Xinhai
2020-01-17 7:57 ` Michal Hocko
2020-01-17 12:05 ` Li Xinhai
2020-01-17 15:20 ` Michal Hocko
2020-01-17 15:46 ` Li Xinhai
2020-01-20 12:45 ` Michal Hocko
2020-01-21 14:15 ` Li Xinhai
2020-01-21 14:53 ` Michal Hocko
2020-01-22 13:55 ` Li Xinhai
2020-01-14 19:12 ` [PATCH 1/2] mm/mempolicy: Checking hstate for hugetlbfs page in vma_migratable Mike Kravetz
2020-01-15 1:25 ` Andrew Morton
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=b1b4a3b1-905f-8dd6-6be7-d55ad04401c2@oracle.com \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=lixinhai.lxh@gmail.com \
--cc=mhocko@suse.com \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=yang.shi@linux.alibaba.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