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.4 required=3.0 tests=CHARSET_FARAWAY_HEADER, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 9E30AC33CB3 for ; Thu, 16 Jan 2020 08:07:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4166A2077B for ; Thu, 16 Jan 2020 08:07:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=necglobal.onmicrosoft.com header.i=@necglobal.onmicrosoft.com header.b="I7x5+t/z" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4166A2077B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=nec.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E845A8E004E; Thu, 16 Jan 2020 03:07:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E35968E003F; Thu, 16 Jan 2020 03:07:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CFD8F8E004E; Thu, 16 Jan 2020 03:07:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0235.hostedemail.com [216.40.44.235]) by kanga.kvack.org (Postfix) with ESMTP id B85C08E003F for ; Thu, 16 Jan 2020 03:07:34 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 5E545181AEF00 for ; Thu, 16 Jan 2020 08:07:34 +0000 (UTC) X-FDA: 76382768028.24.pan43_7c2e34403455 X-HE-Tag: pan43_7c2e34403455 X-Filterd-Recvd-Size: 9739 Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400083.outbound.protection.outlook.com [40.107.140.83]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Thu, 16 Jan 2020 08:07:33 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TWzcl2jJzfx9EVErX/Gk/FZEO1JIP4p2HfcIuB08h4IM96EtBoFpR8gJ4ec2Riytf5l1XakveZompcpFjG+xeO4N/js/6i4kppjBuAVSu2CMiwKslgJyvJvTKSu1aevqcIS4RC3gBKORQFiv5+zlakvrUZAbMtIzeVkAg77lbzqEsZZ0q3IF2Dkd8KH+N7zDzd4sbPAFH+Yb/+4Et/R+N46r1vGeM4t7rBwnv8iwYUS838nmq4RILMfJtDsV7sqH8CGm8OZnIG8vQmbV56JNYUuesrILzEyOcSESgv9ganp4q3bUcvegJhxqHjFwtRiMCj/mpq87wE7G4oYPBJ2VSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JhykJG/W5SMNfZk7huXzJ11I5bMnfDabN91IMAsTveg=; b=KTslGKKtCnJAu7vKMRM+DwnQCGv3RPiJNGvmOJyOcZBbNi1fIgVmldlnEOoNHpWXlrxG553jUwq7OlOv3kJQ7pD6VbLvLTUYmrcV9bVynWjMQ8nARbj3jZevRdiyQY1/pcNADfhQZlKDuIPIMyaKKvlJj4f6guxnug3x53qdcQ3K+GtMJHegveTHulOnXcaAv5SuRtkHoicsvP0zUjABrIqKUBdTqdOxgqbTGDK0mQTIoZFxHAhCqt8J3dqx5Dplv5XGlNXWS//JXiEA4egTyTHT39xiQEiZr5IO+G+8cKpr2Z8v3sAkxmgk7gRR0Ajojxo9i++Bx+XKe4tCR8VbuQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nec.com; dmarc=pass action=none header.from=nec.com; dkim=pass header.d=nec.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=necglobal.onmicrosoft.com; s=selector1-necglobal-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JhykJG/W5SMNfZk7huXzJ11I5bMnfDabN91IMAsTveg=; b=I7x5+t/zPb73osw5Qy2iKAjb29K5euN9P68PXe/6bIzbotuiH2fgHWuU9wn0hX14CcmqvxWPdlLjd5ePzq6Q3XFgAwIFKJKUPaFZFezPiP2qLf7o9cCr3OZFdsCpMKfCyAUWv0ADN3Kacq4HW+eucNSJCYxTq+UYguJmbiV3JNM= Received: from OSBPR01MB1752.jpnprd01.prod.outlook.com (52.134.227.11) by OSBPR01MB2632.jpnprd01.prod.outlook.com (52.134.252.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Thu, 16 Jan 2020 08:07:30 +0000 Received: from OSBPR01MB1752.jpnprd01.prod.outlook.com ([fe80::2de4:5005:518e:7f64]) by OSBPR01MB1752.jpnprd01.prod.outlook.com ([fe80::2de4:5005:518e:7f64%3]) with mapi id 15.20.2623.017; Thu, 16 Jan 2020 08:07:30 +0000 From: =?iso-2022-jp?B?SE9SSUdVQ0hJIE5BT1lBKBskQktZOH0hIUQ+TGkbKEIp?= To: Yang Shi , Mike Kravetz CC: Li Xinhai , "linux-mm@kvack.org" , akpm , mhocko , n-horiguchi Subject: Re: [PATCH 2/2] mm/mempolicy: Skip walking HUGETLB vma if MPOL_MF_STRICT is specified alone Thread-Topic: [PATCH 2/2] mm/mempolicy: Skip walking HUGETLB vma if MPOL_MF_STRICT is specified alone Thread-Index: AQHVyuRAUGUtfOHazEOCdwQ/UbK66qfq6qAAgAFPIICAAAaeAIAAA/GAgAAD9QCAAKnxgA== Date: Thu, 16 Jan 2020 08:07:30 +0000 Message-ID: <20200116080729.GA19016@hori.linux.bs1.fc.nec.co.jp> 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> <2d488bd7-0f2e-f691-b1b6-f2f1faec8ab4@linux.alibaba.com> In-Reply-To: <2d488bd7-0f2e-f691-b1b6-f2f1faec8ab4@linux.alibaba.com> Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=naoya.horiguchi@nec.com; x-originating-ip: [165.225.110.211] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d247f671-1c4a-443e-d16a-08d79a5b2260 x-ms-traffictypediagnostic: OSBPR01MB2632: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(4636009)(39860400002)(366004)(346002)(136003)(396003)(376002)(189003)(199004)(6512007)(6506007)(26005)(110136005)(4326008)(53546011)(1076003)(9686003)(316002)(86362001)(81156014)(33656002)(81166006)(71200400001)(8676002)(66446008)(66556008)(76116006)(85182001)(8936002)(6486002)(54906003)(478600001)(2906002)(66476007)(5660300002)(55236004)(66946007)(91956017)(186003)(64756008);DIR:OUT;SFP:1101;SCL:1;SRVR:OSBPR01MB2632;H:OSBPR01MB1752.jpnprd01.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1; received-spf: None (protection.outlook.com: nec.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Fca3LQyzyb7lrrwuwdPOD2JF6RPpeB7TIEDIQnXpuepp9DVPPZFuMcY2HN6rUU8VfR8n+grGm5feiS8CtvaBRZWdegD0MPMP0CHB3K3O8nft24wUBfC71uxSMDNcke0pYddmJoYy8cEMGDCCGXWyBpQ1KvIERyEjwhGJ0M5fC+M0bM5e+jHQ01QWsm5naJuTNGeEHPVinEruRIxvfovGTqbxPRlKErjzJnJs+jQMLIhRletP1cHQWu+sVlt4h+ts66gZ+qTl7XRaWZs0BDz/MJKa7YbsZchi+ZzkqjH6EtJJU504xmpacZLFZZKWRYweVmAmV5Qt/dB0s26XG8X26FXmDposC4PSYcp80uvHzF5jVditRFjqUJhjNfCMQXPomNrvZkJ51unYqCp2LllzBiIOSI5o2Nqx3U6gKA0OikdNyMLWQ60c4Yg+fG2vrYtD Content-Type: text/plain; charset="iso-2022-jp" Content-ID: <6823CE23DEC5144784B4A9F6CF1E080E@jpnprd01.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nec.com X-MS-Exchange-CrossTenant-Network-Message-Id: d247f671-1c4a-443e-d16a-08d79a5b2260 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2020 08:07:30.3507 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e67df547-9d0d-4f4d-9161-51c6ed1f7d11 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DHhKtS5HJjZ7dWu3POceqgbLiUnkQS3S0nuz/cwZI0h5K5xUM5wb6detiQr+g/aDAmFQxm8a4+pU8RBATMFfHA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB2632 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: Hi everyone, Thank you all for finding and digging the issue. > Summary > =3D=3D=3D=3D=3D=3D=3D > It 'looks' like the statement "MPOL_MF_STRICT is ignored on huge page > mappings." is left over from the original mbind implementation. When > the huge page migration support was added, I can not be sure if ignoring > MPOL_MF_STRICT for huge pages during the verify/isolation phase was > intentional. It seems like it was as the return value from > isolate_huge_page() is ignored. This summary is totally correct. I've simply missed considering MPOL_MF_ST= RICT flag when implementing hugetlb migration. As you pointed out, the discrepa= cy between the manpage and the code is also due to the lack of updates on the "MPOL_MF_STRICT is ignored on huge page mappings." statement. On Wed, Jan 15, 2020 at 01:59:14PM -0800, Yang Shi wrote: >=20 > 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? > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > 1) Nothing more than optimizations by Li Xinhai. Behavior that cou= ld 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 e= asy 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 pa= ge. > > > I don't think we can do this easily since migrate_pages() would put t= he migration failed hugetlb pages back to hugepage_activelist so there shou= ld not any hugetlb page reside on the pagelist regardless of failure if I r= ead the code correctly. Although this behavior seems to me not prevent from finding non-hugetlb pages in migration list, this is a difference in migration behavior between normal pages and hugepages that might be better to be optimized. Maybe hugepages failed to migrate should remain in migration list after migrate_pages() returns and the should be put back via putback_movable_page= s(). > > >=20 > > You are correct. I made an assumption without actually looking at the = code. :( > >=20 > > > Other than that traversing page list to look for a certain type page = doesn't sound scalable to me. > > >=20 > > > > 3) Remove the statement "MPOL_MF_STRICT is ignored on huge page map= pings." > > > > and modify code accordingly. > > > >=20 > > > > My suggestion would be for 1 or 2. Thoughts? > > > By rethinking the history (thanks again for digging into it), it soun= ds #3 should be more reasonable. It sounds like the behavior was changed si= nce hugetlb migration was added but the man page was not updated to reflect= the change. > > >=20 > > 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 behav= ior. > > However, you can never be sure. >=20 > Yes, this would change the bahavior, but I don't see why we have to treat > hugetlb specially nowadays with migration supported. (Option #1 is good for short term solution, but eventually) I agree with op= tion #3. We have no reason to handle hugetlb differently about MPOL_MF_STRICT flag. Thanks, Naoya Horiguchi=