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 1CCFDC54E5D for ; Mon, 18 Mar 2024 10:13:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9D1FC6B0087; Mon, 18 Mar 2024 06:13:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 982866B0089; Mon, 18 Mar 2024 06:13:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 870AA6B0092; Mon, 18 Mar 2024 06:13:50 -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 78EDC6B0087 for ; Mon, 18 Mar 2024 06:13:50 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 49D2B1C0F3C for ; Mon, 18 Mar 2024 10:13:50 +0000 (UTC) X-FDA: 81909748620.02.884022E Received: from out30-97.freemail.mail.aliyun.com (out30-97.freemail.mail.aliyun.com [115.124.30.97]) by imf05.hostedemail.com (Postfix) with ESMTP id 6F84F100025 for ; Mon, 18 Mar 2024 10:13:46 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b="i5/zPefn"; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf05.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.97 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710756827; 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=RVovdAQ+7yisrAzCVk5VJkY+zylsB44T+cg1BQ8q4f4=; b=EygADmy79jDyfbUrF8OeXF78LQCeAayPgqhqVv6xlhkiizeyL3a2I0BMmgFTqTCVL12Rf5 zDKia6w2jfkJIFcOpe4dr9hC/yG+Zhjw7naNLPcOxwFK+SeQlfJsoYcgna9DT/GqkZgf5I gSQEGjT+DrEUGI4la4XwlEEkfSCgKoc= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b="i5/zPefn"; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf05.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.97 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710756827; a=rsa-sha256; cv=none; b=fSMmDRI5tSQ5LTcxm5OH+jleNbLNU/6Uzq7hsZwtzSDtW8Sc+5M2EIN3DdFOeqnqSrfqBe llqHhANoSn+C5SUWkPZ1POydClUtxgGFheb8tT0E/OhF/VnI8psjMbu9pzxfj0rA9b9A/D O7fo/cb6ioQztpcOyVstETj/yfA5olY= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1710756823; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=RVovdAQ+7yisrAzCVk5VJkY+zylsB44T+cg1BQ8q4f4=; b=i5/zPefnNH/kJ9AcebBXHC4dy2DNfowmBsyqZ5YS4lMee3a9ITJ0uKLM81xPKHsSL7m5UAqRGojsWSJnkxKCGs8JZAF1EKE3ptRYgRN0VeV7ojV6XcDmS4nAXL5y9/uOSaEtpQMRIocULsUD1szE2lIzZgH3WPYMrUCfTjqLIE8= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R621e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045168;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0W2mZ7Xx_1710756820; Received: from 30.97.56.66(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0W2mZ7Xx_1710756820) by smtp.aliyun-inc.com; Mon, 18 Mar 2024 18:13:41 +0800 Message-ID: <3bf2c3e1-44fd-4bc8-a97b-9da7b606aec0@linux.alibaba.com> Date: Mon, 18 Mar 2024 18:13:38 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2] mm: support multi-size THP numa balancing To: David Hildenbrand , "Huang, Ying" Cc: akpm@linux-foundation.org, mgorman@techsingularity.net, wangkefeng.wang@huawei.com, jhubbard@nvidia.com, 21cnbao@gmail.com, ryan.roberts@arm.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <903bf13fc3e68b8dc1f256570d78b55b2dd9c96f.1710493587.git.baolin.wang@linux.alibaba.com> <871q88vzc4.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 6F84F100025 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 61e5hngtoiagmj8g6risb3bikyysng6e X-HE-Tag: 1710756826-301576 X-HE-Meta: U2FsdGVkX1/YaHSlxPGh7G8xXtqvsAHcemA5aVjBEoxN+WSdZdudUts/5lSHhkSQ1uJz6uA2L0qQ4Yu8/W+N4clQnrqIsB5IYVtnqRLMHewti2geg5jA+t+RdqcL5AWMkMI0Zyt5jYpoVbI3D9Re+b0RsbGOAU920Fl/uiSkBE8fFzTDn7BhsVKsI+grZXOOEJOro7azN00OKb86ojUlpok7rMnwLIXjct9jF3mnHyhoa/cDtnETRXMYeSbo5JrTftC42nsDzpHQSKVqsw8a5xUIQL594DMg0KfQe0jF9eQJF9lt3V2d1jLjNb+vOVo0WaLovvVSe43Gg+YrVt8/3hS7N1rolHbPQMQSDhLYAbVlX7YcteP/7QrHjizp4wnQxU2GbxcWwnMVNGTsEyZG38kECaMoqC1kpd4vaAswA3mH22cNf14bahncHL6CebeoKh7tCwjUGhVMv5L17SwqYwqfQo9RbympRMieMoMS1LY7dr3pn2uUf8NT/Dcz8tWyt0C0YEJBnq86LFTLToS6oiZVWJPxJWgKFYNSpR7JebkxRp9+Ypao599ujH9K4wCpiaeoS/5GARHDDPxNw5k+U4txXbt1xDoa3qzLFa7r5pYfBxLdPhYTjk6ajTmzakRIMlhHAmCJn0Y2M3p4kKTyhrkG2C7o6O7ItAtcOLwJBxAUP7u+8f54CKdkmEyD3+ELGJ8bdDrIROfbodbPI4vYHTd+rtuTYru3DwcgLjkUT4HZM6ES3Z/BSlz7FxChm173DLqZ6Vj3apfA7kKCl3c/keKrFBlkCOuDRwxsE51soljHbImtoZ42zCAwgKbyCHwWSgeLB0iIFYspuSv1chouMP450pDr1axTHpGUcVzupFnQO0hsGeSBsCHXd+0TCtRuxm24J7g874MEZo8mi9oERN1EQ4q/FY0elDmOmdwSecQXVNN9Q9gvV/hPRqwxvuKhT9075PNwaS+x8K7VehE aUETyY7L oVtCZZK79Gv3iUWEO/pSnlgXWy3HqHTZNSr1A4pgP5b9CZgrM6x6kK7zqVP8iDpQ84i6ZlvN2MsvF2bf2OXbCZd5XNKqkeVClXhAzA4eluC7ZQ9L7faT20qpPnAzEQ7iLNjC/rJHcniUb9pajO7qjRUqeAihE6ynL2kj2LUhroSCVNHZBSwOYQPDQi/td3SVppiGR2ZjI4nP+WWehlLrG2biVyn8bMxOZExwZRFPUZr0Jm+cgfT7bw/97LzSMbbmDxaypN2AWeTlEJ1f7xQv9G8eKPkG7ZZcAoj2qAhJTgPV8rcEudRS+TfqWraX4t7Y1glXnSxSUJqXqwalyEsjYR4xSCNh56ylm6Cux 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: List-Subscribe: List-Unsubscribe: On 2024/3/18 17:48, David Hildenbrand wrote: > On 18.03.24 10:42, Baolin Wang wrote: >> >> >> On 2024/3/18 14:16, Huang, Ying wrote: >>> Baolin Wang writes: >>> >>>> Now the anonymous page allocation already supports multi-size THP >>>> (mTHP), >>>> but the numa balancing still prohibits mTHP migration even though it >>>> is an >>>> exclusive mapping, which is unreasonable. Thus let's support the >>>> exclusive >>>> mTHP numa balancing firstly. >>>> >>>> Allow scanning mTHP: >>>> Commit 859d4adc3415 ("mm: numa: do not trap faults on shared data >>>> section >>>> pages") skips shared CoW pages' NUMA page migration to avoid shared >>>> data >>>> segment migration. In addition, commit 80d47f5de5e3 ("mm: don't try to >>>> NUMA-migrate COW pages that have other uses") change to use >>>> page_count() >>>> to avoid GUP pages migration, that will also skip the mTHP numa >>>> scaning. >>>> Theoretically, we can use folio_maybe_dma_pinned() to detect the GUP >>>> issue, although there is still a GUP race, the issue seems to have been >>>> resolved by commit 80d47f5de5e3. Meanwhile, use the >>>> folio_estimated_sharers() >>>> to skip shared CoW pages though this is not a precise sharers count. To >>>> check if the folio is shared, ideally we want to make sure every >>>> page is >>>> mapped to the same process, but doing that seems expensive and using >>>> the estimated mapcount seems can work when running autonuma benchmark. >>>> >>>> Allow migrating mTHP: >>>> As mentioned in the previous thread[1], large folios are more >>>> susceptible >>>> to false sharing issues, leading to pages ping-pong back and forth >>>> during >>>> numa balancing, which is currently hard to resolve. Therefore, as a >>>> start to >>>> support mTHP numa balancing, only exclusive mappings are allowed to >>>> perform >>>> numa migration to avoid the false sharing issues with large folios. >>>> Similarly, >>>> use the estimated mapcount to skip shared mappings, which seems can >>>> work >>>> in most cases (?), and we've used folio_estimated_sharers() to skip >>>> shared >>>> mappings in migrate_misplaced_folio() for numa balancing, seems no real >>>> complaints. >>> >>> IIUC, folio_estimated_sharers() cannot identify multi-thread >>> applications.  If some mTHP is shared by multiple threads in one >> >> Right. >> > > Wasn't this "false sharing" previously raised/described by Mel in this > context? Yes, I got confused with the process's false sharing. >>> process, how to deal with that? >> >> IMHO, seems the should_numa_migrate_memory() already did something to >> help? >> >> ...... >>     if (!cpupid_pid_unset(last_cpupid) && >>                 cpupid_to_nid(last_cpupid) != dst_nid) >>         return false; >> >>     /* Always allow migrate on private faults */ >>     if (cpupid_match_pid(p, last_cpupid)) >>         return true; >> ...... >> >> If the node of the CPU that accessed the mTHP last time is different >> from this time, which means there is some contention for that mTHP among >> threads. So it will not allow migration. >> >> If the contention for the mTHP among threads is light or the accessing >> is relatively stable, then we can allow migration? >> >>> For example, I think that we should avoid to migrate on the first fault >>> for mTHP in should_numa_migrate_memory(). >>> >>> More thoughts?  Can we add a field in struct folio for mTHP to count >>> hint page faults from the same node? >> >> IIUC, we do not need add a new field for folio, seems we can reuse >> ->_flags_2a field. But how to use it? If there are multiple consecutive >> NUMA faults from the same node, then allow migration? > > _flags_2a cannot be used. You could place something after _deferred_list Could you be more explicit? I didn't see _flags_2 currently being used, did I miss something? > IIRC. But only for folios with order>1. Yes, order 1 folio may use the same strategy with order 0, but need some evaluation. > But I also wonder how one could achieve that using a new field.