From: Yang Shi <email@example.com> To: Mike Kravetz <firstname.lastname@example.org>, Li Xinhai <email@example.com>, "firstname.lastname@example.org" <email@example.com> Cc: akpm <firstname.lastname@example.org>, mhocko <email@example.com>, n-horiguchi <firstname.lastname@example.org> Subject: Re: [PATCH 2/2] mm/mempolicy: Skip walking HUGETLB vma if MPOL_MF_STRICT is specified alone Date: Wed, 15 Jan 2020 13:59:14 -0800 Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On 1/15/20 1:45 PM, Mike Kravetz wrote: > On 1/15/20 1:30 PM, Yang Shi wrote: >> On 1/15/20 1:07 PM, 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. >> I don't think we can do this easily since migrate_pages() would put the migration failed hugetlb pages back to hugepage_activelist so there should not any hugetlb page reside on the pagelist regardless of failure if I read the code correctly. >> > You are correct. I made an assumption without actually looking at the code. :( > >> Other than that traversing page list to look for a certain type page doesn't sound scalable to me. >> >>> 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? >> By rethinking the history (thanks again for digging into it), it sounds #3 should be more reasonable. It sounds like the behavior was changed since hugetlb migration was added but the man page was not updated to reflect the change. >> > Let's hope Naoya comments. My only concern with #3 is that we will be changing > behavior. I do not think many people (if any) depend on existing behavior. > However, you can never be sure. Yes, this would change the bahavior, but I don't see why we have to treat hugetlb specially nowadays with migration supported.
next prev parent reply index 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 [this message] 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 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 publically 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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
Linux-mm Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \ email@example.com public-inbox-index linux-mm Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kvack.linux-mm AGPL code for this site: git clone https://public-inbox.org/public-inbox.git