From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CBCB9C32771 for ; Wed, 15 Jan 2020 21:59:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 965452465A for ; Wed, 15 Jan 2020 21:59:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 965452465A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 17D748E000C; Wed, 15 Jan 2020 16:59:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 107EE8E0003; Wed, 15 Jan 2020 16:59:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F37778E000C; Wed, 15 Jan 2020 16:59:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0070.hostedemail.com [216.40.44.70]) by kanga.kvack.org (Postfix) with ESMTP id D79D38E0003 for ; Wed, 15 Jan 2020 16:59:28 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 7A4A5181AC9B6 for ; Wed, 15 Jan 2020 21:59:28 +0000 (UTC) X-FDA: 76381235616.11.color66_529160f72f41e X-HE-Tag: color66_529160f72f41e X-Filterd-Recvd-Size: 3673 Received: from out30-131.freemail.mail.aliyun.com (out30-131.freemail.mail.aliyun.com [115.124.30.131]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Wed, 15 Jan 2020 21:59:26 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R101e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e07484;MF=yang.shi@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0Tnq9NaA_1579125554; Received: from US-143344MP.local(mailfrom:yang.shi@linux.alibaba.com fp:SMTPD_---0Tnq9NaA_1579125554) by smtp.aliyun-inc.com(127.0.0.1); Thu, 16 Jan 2020 05:59:17 +0800 Subject: Re: [PATCH 2/2] mm/mempolicy: Skip walking HUGETLB vma if MPOL_MF_STRICT is specified alone To: Mike Kravetz , Li Xinhai , "linux-mm@kvack.org" Cc: akpm , mhocko , n-horiguchi References: <1578993378-10860-1-git-send-email-lixinhai.lxh@gmail.com> <1578993378-10860-2-git-send-email-lixinhai.lxh@gmail.com> <2020011422092314671410@gmail.com> <9fabdc16-fc31-7e06-e306-af38850de771@linux.alibaba.com> <52a03774-f6cd-c66b-6d27-ebf74aa7a850@oracle.com> From: Yang Shi Message-ID: <2d488bd7-0f2e-f691-b1b6-f2f1faec8ab4@linux.alibaba.com> Date: Wed, 15 Jan 2020 13:59:14 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <52a03774-f6cd-c66b-6d27-ebf74aa7a850@oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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.