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 A535CC3DA4A for ; Fri, 9 Aug 2024 10:31:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA59B6B007B; Fri, 9 Aug 2024 06:31:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E554D6B0089; Fri, 9 Aug 2024 06:31:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1CF36B008A; Fri, 9 Aug 2024 06:31:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B1FF46B007B for ; Fri, 9 Aug 2024 06:31:27 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 689A1140CB9 for ; Fri, 9 Aug 2024 10:31:27 +0000 (UTC) X-FDA: 82432340214.09.21F7BE8 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf18.hostedemail.com (Postfix) with ESMTP id 6A0691C0025 for ; Fri, 9 Aug 2024 10:31:25 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Z/tgXv4e"; spf=pass (imf18.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723199398; 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=+H3eyHtXbgtv4OaC7MvOOPUY9/9WMhUrsBtexcGajXA=; b=j449/yjFt57k1mxTPstCiXVWvHQ2z6AD2/KorP4WkGYxL9ly7rupfCUNbwyqHCGQ7SxMvT /4JWtn2AHUk5l6AMIpomYWf0GOINkgawpL/C1lLYXd0iRLchtt8+PFHncLykiFg9ZlliIH Sx2neIJ8daWmoCUJkay4syeArykr8SE= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Z/tgXv4e"; spf=pass (imf18.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723199398; a=rsa-sha256; cv=none; b=dy6sT5iB5GbbwIhwTCirlaRCZkjiG5cSCy6vxEfP0240jRJL8kJ9Srq8cIZgD3mn56UAzV ZVNVyZTKkdfD/t2SV2+T2B68RtXget1LrMS3pZKGMetewKPN5ytoqKEUVeYBoNYulf6tmM AjeIy0satu/3PX6UD2l8G89NohlodHw= Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-5b391c8abd7so2229106a12.2 for ; Fri, 09 Aug 2024 03:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723199484; x=1723804284; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=+H3eyHtXbgtv4OaC7MvOOPUY9/9WMhUrsBtexcGajXA=; b=Z/tgXv4eGXdjE+krRmmjkf6mVxfQKR1lwxZKkVtaFd0eK2+DWhU+VSGDwUanLHBXcv yY0B+vGueeRz3ATxEoYU3OgL8JK69TOfMwCE3rexXCTYQC+hcQP0w9Jd0bOhW/KKXpnu fbo3jEDEyWVEnCub3XZA9CROlzdXSzupQR4vswOAk8FQA03MhcRpNq/VUONPEL9D6fCv kM+fOGXjuaF7Wf94ZW3I9Ekafe0jaHQTvm/8+o5nMoQEZsc6hIGmUCM9c3mvQigdoqhr 36gylJkxBE7rZF+jsP+Qnf/vrF4V0NNAYnGgwx/XQO6MZ6jjI/clsI30KlCSYO3HdLj8 eVKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723199484; x=1723804284; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+H3eyHtXbgtv4OaC7MvOOPUY9/9WMhUrsBtexcGajXA=; b=kNdYt/gwbmOBeztlT5+Z26vHxQuGEcxGumuY+ts9Bz4bIukGLdN7EOUBRB1hhRyytV D2jMd5XY4dfLemsHU0TuApsMi3JaQJm+HCkjDnlSuzrU0IaNcWqcXLfwjlXYJk3POJmA Jf1Wu3r5stPLuTZ7wAvbhP0srcWqDTG9SDFUJYXna2+rxGQUORPGDrd6XNWpnaAdgo1t J+wLFyjgfIT9w5xdEClJ74fOfHN0G2wwAX151f1Ik2X7279jOS2ANppe7TqQWaUZOugy DlhcmyTU247LnUlBQWT73vST6swlTZUhDJF6YScJRAUXpEj9wpnIC+89BYznalh9LJ8n PZkA== X-Forwarded-Encrypted: i=1; AJvYcCVoJvrtNpUWU0KlXo9iMGDEW4icqUaUA761+4GLswWhDty7CjzanNzO/skzxioPjdYdeazl1fVb3w==@kvack.org X-Gm-Message-State: AOJu0Yw9qGyuSD/Ex+Jk8dRelDBl/1xunj2TIui8K+K1MvcFGVrHP/ks IXViuizbmbPV+r94e0SoVZJGvhb+oZx1w7ziMZjaOBi8mhycdjJ2 X-Google-Smtp-Source: AGHT+IEQGpPT26AOYC9chXY6sOBc3bShNjn3DG5YtMRlhutES2lt4BeO3HvDqYZ3czZyw6CPjqUUeA== X-Received: by 2002:a05:6402:3885:b0:5bb:9ae0:4a47 with SMTP id 4fb4d7f45d1cf-5bd0a56681cmr673021a12.17.1723199483082; Fri, 09 Aug 2024 03:31:23 -0700 (PDT) Received: from ?IPV6:2a03:83e0:1126:4:eb:d0d0:c7fd:c82c? ([2620:10d:c092:500::6:b73e]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5bbb2d35351sm1400544a12.60.2024.08.09.03.31.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Aug 2024 03:31:22 -0700 (PDT) Message-ID: Date: Fri, 9 Aug 2024 11:31:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/4] mm: split underutilized THPs To: David Hildenbrand , akpm@linux-foundation.org, linux-mm@kvack.org Cc: hannes@cmpxchg.org, riel@surriel.com, shakeel.butt@linux.dev, roman.gushchin@linux.dev, yuzhao@google.com, baohua@kernel.org, ryan.roberts@arm.com, rppt@kernel.org, willy@infradead.org, cerasuolodomenico@gmail.com, corbet@lwn.net, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, kernel-team@meta.com References: <20240807134732.3292797-1-usamaarif642@gmail.com> <20240807134732.3292797-5-usamaarif642@gmail.com> <5adb120e-5408-43a6-b418-33dc17c086f0@redhat.com> Content-Language: en-US From: Usama Arif In-Reply-To: <5adb120e-5408-43a6-b418-33dc17c086f0@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 6A0691C0025 X-Stat-Signature: hmf4k1dyerq99z4rqz55ebupe5ph67rs X-Rspam-User: X-HE-Tag: 1723199485-309594 X-HE-Meta: U2FsdGVkX1/dzh7l+XwxNpJKx5OjeVeF+tcuhRtqNZZTz/LXA+D1hLO2e6+ahW2XjGWp4VFwOJoe4Q67MT5bEhHpwhBi9s5NR7dJFL0l8vQEVSvxoiZqZCr6wZ0JV5hgAlVsGloigvGec43k5PPCXOFFTNcdFyRzGtum67jEw1O3cw+d46zKKU8IHxcQ92+T//QVhq2F5JlCieTcBW6M8b2y+YMkxawiPXcC4bnZSXH+H39j+929MM7fkcy03uMa3OTU70G9O2gl3GKk5r3SR2gwX5sdpsRkKTtk7Wipvu4LImOgyRHaKYM/0fSiQ6ptVQ0GHTAxLQGR7nyCL6MzkOmSaxo7/RAtMhqqahfWKMKy/v26L1e0ElAMTvhdR22+vNu3C85bQ5AceiJF667uhNiIXptAqDCaeM65zpp63gKCeVKDloCJSp4dVS7ttngrfIX6KBtwV5+m6W1QL1tVOHcC99lTu1JfMpbdoYfOCl1eOv2qiMHZ7fNQYuh+RARrDZ8prTcw+bUEy4wCE3aLDP71VMy65laEKRDpkshPBMKxmvwcPT2bMYLv4v73jyO1c7lnwuEzZTbojHjIocCxpuCKJg29NOS8tfLnHYfL6625ZbEJFeJZNigmExNoF5zWQYkBGPMgyzXpNcJsdA9Y5djvbYAoMyo0/D91SoCyvjJgpYkYMJdv0FGZPmoAwTqScv0DPdgXOzdYQCkhbKl/RUZxvcvoF+Mcud2yWqnTV4SVSPr1FgWCXhxYxa+uw+Y+OfjpPJLaJ94cVXnJidZdd1KW5qWPIU9D9wcLWh4m1I22ff/WdUo0qTo58bnONpuKJ8ii1+nJXGQvBCEUcz+Q2D9q06s/L7U0t4I7UNBn+jIlzf0KHKg65XP0KZpLd7qrXSZSojXJz7Ve5EFHBM05vZ2RCxSRyp5srX/5AV5XNRtwE4S/56fAaO5HDdR9GErBylxazEFBrrMZFTycIeE Nw8wusuy HuGbIKfgTM4D6euDP6hj5eVXLHZa31v1+SKpbr0+YHih3IEYsxkEB24jVuQGLo333qbcdWWlnWzVY4e42XpTLLFPvstuy7aXIGj8bfEU8ACo+XIruEpl8QaapME68iWKLGYJ87cLAQ2wnEUv97Em2TBpu3hAn9ozoSQHFW1Dm2t/DshW9TrWBY6aZUqGiaEq8maeUbg7VGPfNp4f9YkoK+js9Rj7aAWEKJWYhZkC0GYGtGGXCu7JgQ/xzf4j3wXMpxHqFK4G4vMFMIZi8NuaS23q9+e7mnVv6sfNiGTYoju/S7HZ/jH3geNrut9Y2+esUBsUrbrmRPiV3LTNtlVDKkD25z3Yz7J75KZ6Ya53yTe+/DgEftRtZaAlIcMs+GJHCxNLeLaNzYsLLR/GVLdsKPKOiabWyb5IDJMzugLMG5x31HIHea0roBMZK0jlhFCGZp9tec0tEMEeSm57wXbb0XdESaiXY7N+jPndf0L1ilP6+E4cVU+CVhev8UQ== 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 08/08/2024 16:55, David Hildenbrand wrote: > On 07.08.24 15:46, Usama Arif wrote: >> This is an attempt to mitigate the issue of running out of memory when THP >> is always enabled. During runtime whenever a THP is being faulted in >> (__do_huge_pmd_anonymous_page) or collapsed by khugepaged >> (collapse_huge_page), the THP is added to  _deferred_list. Whenever memory >> reclaim happens in linux, the kernel runs the deferred_split >> shrinker which goes through the _deferred_list. >> >> If the folio was partially mapped, the shrinker attempts to split it. >> A new boolean is added to be able to distinguish between partially >> mapped folios and others in the deferred_list at split time in >> deferred_split_scan. Its needed as __folio_remove_rmap decrements >> the folio mapcount elements, hence it won't be possible to distinguish >> between partially mapped folios and others in deferred_split_scan >> without the boolean. > > Just so I get this right: Are you saying that we might now add fully mapped folios to the deferred split queue and that's what you want to distinguish? Yes > > If that's the case, then could we use a bit in folio->_flags_1 instead? Yes, thats a good idea. Will create the below flag for the next revision diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h index 5769fe6e4950..5825bd1cf6db 100644 --- a/include/linux/page-flags.h +++ b/include/linux/page-flags.h @@ -189,6 +189,11 @@ enum pageflags { #define PAGEFLAGS_MASK ((1UL << NR_PAGEFLAGS) - 1) +enum folioflags_1 { + /* The first 8 bits of folio->_flags_1 are used to keep track of folio order */ + FOLIO_PARTIALLY_MAPPED = 8, /* folio is partially mapped */ +} + #ifndef __GENERATING_BOUNDS_H and use set/clear/test_bit(FOLIO_PARTIALLY_MAPPED, &folio->_flags_1) in the respective places. > > Further, I think you forgot to update at least one instance if a list_empty(&folio->_deferred_list) check where we want to detect "partially mapped". Please go over all and see what needs adjustments. > Ah I think its the one in free_tail_page_prepare? The way I wrote this patch is by going through all instances of "folio->_deferred_list" and deciding if partially_mapped needs to be set/cleared/tested. I think I missed it when rebasing to mm-unstable. Double checked now and the only one missing is free_tail_page_prepare ([1] was removed recently by Barry) [1] https://lore.kernel.org/lkml/20240629234155.53524-1-21cnbao@gmail.com/ Will include the below diff in the next revision. diff --git a/mm/page_alloc.c b/mm/page_alloc.c index aae00ba3b3bd..b4e1393cbd4f 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -957,8 +957,9 @@ static int free_tail_page_prepare(struct page *head_page, struct page *page) break; case 2: /* the second tail page: deferred_list overlaps ->mapping */ - if (unlikely(!list_empty(&folio->_deferred_list))) { - bad_page(page, "on deferred list"); + if (unlikely(!list_empty(&folio->_deferred_list) && + test_bit(FOLIO_PARTIALLY_MAPPED, &folio->_flags_1))) { + bad_page(page, "partially mapped folio on deferred list"); goto out; } break; > I would actually suggest to split decoupling of "_deferred_list" and "partially mapped" into a separate preparation patch. > Yes, will do. I will split it into 3 patches, 1st one that introduces FOLIO_PARTIALLY_MAPPED and sets/clear it in the right place without introducing any functional change, 2nd to split underutilized THPs and 3rd to add sysfs entry to enable/disable the shrinker. Should make the patches quite small and easy to review.