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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 39853C001B0 for ; Tue, 15 Aug 2023 03:59:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C8B1D90001A; Mon, 14 Aug 2023 23:59:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C3B4F90000B; Mon, 14 Aug 2023 23:59:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B039290001A; Mon, 14 Aug 2023 23:59:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 9F11F90000B for ; Mon, 14 Aug 2023 23:59:44 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 5DD7C4023E for ; Tue, 15 Aug 2023 03:59:44 +0000 (UTC) X-FDA: 81124985088.26.942EF19 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) by imf08.hostedemail.com (Postfix) with ESMTP id C26F2160018 for ; Tue, 15 Aug 2023 03:59:41 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=CX9NeYPl; spf=pass (imf08.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692071982; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=PW+KdJiwScapJzPHq1sTkChoiJXnWODMmV4rqLKiaMc=; b=RJXZUpRo91qtDAtL+c278B+ReEYpCxHgslVT1ScKzyytc+R5y42i9WuBvtRyOAyEljx+TD +00ryOAAA2OfYtRywkPvrWUwOoaqsS98Q88fjgHcs6r6gTpwJilWHR4W89C9m1crB8QIo5 jy9R72SXE6IY9TNGfJxqKld/KbERVas= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692071982; a=rsa-sha256; cv=none; b=wMbvTg0MSD3Y9fTWsn9VJt4Y5mLHLGdWpvlW2YoW6vY1G9wPRRzrptSf0e/YyKSukn3c1b l3G5gZGZNuEi0K78tIdxty8PS5aT3ILOvJfCYmW7EjsOHsl64bampk034ZQo0QH3flxY1k tTR8RhPulVd9468U773iYXAv+4Sd3oo= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=CX9NeYPl; spf=pass (imf08.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1692071982; x=1723607982; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version:content-transfer-encoding; bh=/Mw7RQpLyqhx6Q6WsAXyrv5pUB4TROjZEdCTqb4BKLA=; b=CX9NeYPlXQ9T7Jqmr8dBHrIPF413R3/O3YMcl9zTv0acm22MVKT3KF7T qYXePcuTJUB2uNiWRHdM0fT5qqADCecxSLP9Pw7Epede/90pQLtd7RMOW NulIKxtfOP6DizBVJDUYw+/ZqQFtTSkt5qFRkcBFoyBfONc6wQBOtmPcU ubgU6Zb4p2W9LmzUl2QstNY4mqFW0xrGx7lUCFNTARc4uZh05RaDdQfRL ZrQCPIlMRzA6/6c6tXycGc0Z11yqt62ByfJBZ3FmdTKO8eM6umRpCBJCk LKiEH6Vr8q98510r0CitCFi+9TDc8pfaq18eHR5mTOZqt5WbEl8tiEgCS w==; X-IronPort-AV: E=McAfee;i="6600,9927,10802"; a="371101942" X-IronPort-AV: E=Sophos;i="6.01,173,1684825200"; d="scan'208";a="371101942" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Aug 2023 20:59:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10802"; a="803672393" X-IronPort-AV: E=Sophos;i="6.01,173,1684825200"; d="scan'208";a="803672393" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Aug 2023 20:59:38 -0700 From: "Huang, Ying" To: Kefeng Wang , Mike Kravetz Cc: Zi Yan , Naoya Horiguchi , Matthew Wilcox , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, David Hildenbrand Subject: Re: [PATCH 1/4] mm: migrate: use a folio in add_page_for_migration() References: <5BBFF5D3-3416-4C0E-9FDD-655661657D67@nvidia.com> <20230809205316.GA3537@monkey> <20230809224424.GB3537@monkey> <2da95492-079b-43b1-a950-d290984a21c0@huawei.com> <20230810162920.GA4734@monkey> Date: Tue, 15 Aug 2023 11:58:00 +0800 In-Reply-To: <20230810162920.GA4734@monkey> (Mike Kravetz's message of "Thu, 10 Aug 2023 09:29:20 -0700") Message-ID: <87wmxx7y9j.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: C26F2160018 X-Rspam-User: X-Stat-Signature: aqznb4z7tngco6t95hkzcuigtu63ykn4 X-Rspamd-Server: rspam03 X-HE-Tag: 1692071981-636349 X-HE-Meta: U2FsdGVkX1/aIAeezUQZ/q6BJ2P8NXJ3ARVUcppWwo117CahRGUcVfNuIA32kkAluZlilSfDG3mBvfy6BS7RsgNBdEqx0MO16PdF32ferS6gFXKZ3V8xpJc0LTzH+N3RuCJ+rEw24hf3Gu4z8LtzMGE7ecKR2u7ube3x9Qt5B5sbT2sT4HrN/ZCtvGl2pImPPCRc76e1srNaRH30tM6PEem8whl/Xi8bpEqUnXlkreQ6Q8KgvewlPzwDd9TTQYgXWgSpR5N9C8jMenLi0WL+T7rceOVHznmyUi9qmDEtOCBegpMgGzzeGjPsZhkarKzQP9+17octoHf5wF9nWraktS17CIe3n8p1DPpK4AdvIBJ9OLmzDc7G2LWgXMryVJQPqjTcB4SD2teE6mAEBqI17BgAp0A8kUqnPJATEM3pIbdCWcIqbSC6k7W+3twt62LRkvD/QZtIbPz2kYiPk7wWMJj/3a/aH3KbTkxv/e/VQmqmdPAB8yoBivaJxHbaIC0h7hHkWSkeRXLUoRPB9T4tcYyvYMMkkRy+1XwR3KWjmnO9wKWsK6gcN1OLecAcEa1JMHhkobsyyQWkRTJvxB7GmC13r0xpTgmsIlHBZ1ugV13ABRLuk9FBudmLLgbHHDBSa0Uz1d4eKGPKn0xNZLSEAQlAVGnMAktOGNACfQz7VXCO7J7VmonUFP4hNeENioZeernk9FO2VcbdXyIzwqpnZ33uXjj61cnuQdh+Pfq/neXmIkJp6JuhyKhrU0F+wwSNXRgNJIH0Ibd14tuB5+u0ry4SFxIibwhLH9Spk2ZQk3qXkgiy40q0aR+vqfXe2XodW5qUL7m6m8GJZ56gwVry5WUO5q+jvbcgRcIe/CNpR8Wg3IAArwV1q/aP3rSxhO+CMJ+JlYpaJyj6QVp7KPX6t9zEwunitzAAwd/kElpcN2Q61jwZqlREU+EYjzeeCvTbiMoZsI1ErFQW+ka5vgM 4qFTKdYE 84ZJLSeRO26anRs+H4lUHcKrRX/5XFXIH/VoFCa76RCNeoHjzRqGJigcUuAzGMamEpWEm7NyKMLtWrIuvpcjfDGy1KnPKocHZHCHq7ODZomdACBlHJDHzH9EIfrqVD7m8sEYYZdny93FB2cI/4RfHdYv38zr8+rURDKGbKAFnTvm5LR60j3BMzWR8hNHT+Xtgysf0DYouSR0twq5H/4hmByxCWw== 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: Mike Kravetz writes: > On 08/10/23 09:49, Kefeng Wang wrote: >>=20 >>=20 >> On 2023/8/10 6:44, Mike Kravetz wrote: >> > On 08/09/23 13:53, Mike Kravetz wrote: >> > > On 08/09/23 20:37, Kefeng Wang wrote: >> > > > >=20 >> > > > > Cc Mike to help us clarify the expected behavior of hugetlb. >> > > > >=20 >> > > > > Hi Mike, what is the expected behavior, if a user tries to use m= ove_pages() >> > > > > to migrate a non head page of a hugetlb page? >> > > >=20 >> > > > Could you give some advise, thanks >> > > >=20 >> > >=20 >> > > Sorry, I was away for a while. >> > >=20 >> > > It seems unfortunate that move_pages says the passed user addresses >> > > should be aligned to page boundaries. However, IIUC this is not che= cked >> > > or enforced. Otherwise, passing a hugetlb page should return the sa= me >> > > error. >> > >=20 >> > > One thought would be that hugetlb mappings should behave the same >> > > non-hugetlb mappings. If passed the address of a hugetlb tail page,= align >> > > the address to a hugetlb boundary and migrate the page. This change= s the >> > > existing behavior. However, it would be hard to imagine anyone depe= nding >> > > on this. >> > >=20 >> > > After taking a closer look at the add_page_for_migration(), it seems= to >> > > just ignore passed tail pages and do nothing for such passed address= es. >> > > Correct? Or, am I missing something? Perhaps that is behavior we w= ant/ >> > > need to preserve? >> >=20 >> > My mistake, status -EACCES is returned when passing a tail page of a >> > hugetlb page. >> >=20 >>=20 >> As mentioned in previous mail=EF=BC=8C before e66f17ff7177 ("mm/hugetlb:= take >> page table lock in follow_huge_pmd()") in v4.0, follow_page() will >> return NULL on tail page for Huagetlb page, so move_pages() will return >> -ENOENT errno, but after that commit, -EACCES is returned. >>=20 >> Meanwhile, the behavior of THP/HUGETLB is different, the whole THP will = be >> migrated on a tail page, but HUGETLB will return -EACCES(after v4.0) >> or -ENOENT(before v4.0) on tail page. >>=20 >> > Back to the question of 'What is the expected behavior if a tail page = is >> > passed?'. I do not think we have defined an expected behavior. If >> > anything is 'expected' I would say it is -EACCES as returned today. >> >=20 >>=20 >> My question is, >>=20 >> Should we keep seem behavior between HUGETLB and THP, or only change the >> errno from -EACCES to -ENOENT/-EBUSY. > > Just to be clear. When you say "keep seem behavior between HUGETLB and T= HP", > are you saying that you would like hugetlb to perform migration of the en= tire > hugetlb page if a tail page is passed? > > IMO, this would be ideal as it would mean that hugetlb and THP behave the= same > when passed the address of a tail page. The fewer places where hugetlb > behavior diverges, the better. However, this does change behavior. A separate patch will be needed for behavior change. > As mentioned above, I have a hard time imagining someone depending on the > behavior that passing the address of a hugetlb tail page returns error. = But, > this is almost impossible to predict. > > Thoughts from others?=20=20 -- Best Regards, Huang, Ying