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 43F8FC48BF6 for ; Mon, 26 Feb 2024 17:41:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE4FF6B0081; Mon, 26 Feb 2024 12:41:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A95906B0085; Mon, 26 Feb 2024 12:41:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 95D366B0088; Mon, 26 Feb 2024 12:41:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 85D896B0081 for ; Mon, 26 Feb 2024 12:41:13 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6728940959 for ; Mon, 26 Feb 2024 17:41:13 +0000 (UTC) X-FDA: 81834671226.08.09E9284 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf17.hostedemail.com (Postfix) with ESMTP id 9F6EC40011 for ; Mon, 26 Feb 2024 17:41:10 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf17.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708969271; 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; bh=7Eo5ptl+csIuQRO4g7aw+yq6rgTcb4eqzCYIiJEzifQ=; b=A7FM5RfPZo4nTpo05jp+KPxkbgwVeYEDy9DcNW562CQHuyblBRzFrBhk3eFrodECAgHT+0 /tedJ0ih5+ccNa8R4WGUfQ0Md9DRgGf3Ca5fH9ff9jvUccBVrwxRtGUOI5dLoQXvQTej3o Qn/z2hFpJZiRqrgdkdJ5g43HjuENCHQ= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf17.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708969271; a=rsa-sha256; cv=none; b=NGATwaLSQXfcAsQ+28os0Le+KBVowaWY6nWrbjWcuAEadK+yWEyinG8lbV48oHtIc8kiEq EalARk8qSQe5pnlb0QPwnsZZQiCa3ixfc862OZHKMhcg4vkkxl36Yy/RwR/mBupQGD1B9J W4/2YH0QxwoNjOiySN8QJljrnqhJn2Y= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2FEF9DA7; Mon, 26 Feb 2024 09:41:48 -0800 (PST) Received: from [10.57.67.4] (unknown [10.57.67.4]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E95DC3F73F; Mon, 26 Feb 2024 09:41:07 -0800 (PST) Message-ID: Date: Mon, 26 Feb 2024 17:41:06 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/4] mm: swap: Remove CLUSTER_FLAG_HUGE from swap_cluster_info:flags Content-Language: en-GB To: David Hildenbrand , Andrew Morton , Matthew Wilcox , Huang Ying , Gao Xiang , Yu Zhao , Yang Shi , Michal Hocko , Kefeng Wang Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20231025144546.577640-1-ryan.roberts@arm.com> <20231025144546.577640-2-ryan.roberts@arm.com> <6541e29b-f25a-48b8-a553-fd8febe85e5a@redhat.com> From: Ryan Roberts In-Reply-To: <6541e29b-f25a-48b8-a553-fd8febe85e5a@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 9F6EC40011 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: nups4y3frun4mjcgeh8o6gzti7hiyqho X-HE-Tag: 1708969270-301949 X-HE-Meta: U2FsdGVkX19yRLPbhMLFJCiPw0jt1NN8pO2yIdpNCmM4kuGW3/ss9MnG6MlP2rRAOObjvVg44ptL0VGqfCS7GTku59JxxAL/+jDmcyrAnzyB/wGBFmfoSRdjS8TYaFoAzkZoECBzSBKWGV+/du0Kh8jI9uU2EW4oL2T3i9tNiuVqlPYnoVXerArNYzkzmmsLywqjaIrwFV2UxVEekHje63HXfUVy18GOlRuINKZajjCjjO9dKFNJECRY6MbMf8oeaFrTCrcswJFSZBMZIz1hfPh/qU4aF9lavwvNMtZZvVGopj8U8utCkdirPPTDNEG3/F9SnZG8/M02okDZcfxLzKOoz46JiMhjzvoz171ACfvbMzNvf0ToJ2qaTJ8l51Oy5WpDQ8dP+Jbb66R3YsFVd0SF2SOvyBk38Nefubpn9U+KoveqtCUyFXyqEty8DLX2Qcb48AS+8iYZ3oyf8s4m5qeAs6wiPUwJZ1yIurBSemewHbQc5X11PhFXTs8aP2HHYjuDvWSS3w+tLu1AgSgrqhkwZxS2DJeUJb4qUcMNxhAxoMEum878X00EAVu7bPcDe17kH5eGxSrW3amDi+SpzOakuvJ1O+/RCd53e6b58HmW/DDkEgffI6+RSo2siQ408zgDEO7fxBPyDIiBeP+Qfu/xACJGdB3QnvUA7cZwIwHr1DYw3vO5mF35cMaSiLHlk9A+/SsLvL+FZj2srX3czZHwba7FH94WFQiHe0T3QBo5vnk4h9MfNn/jbaFjhXoePKY8gCqmiihD4fw7IswkdkDTJNAWtbcrOWEqDTP+lUT15w1kJz8sa1kIs/8iIPR854W9RF4sMNJEXp3SZRRqoBuG0A/W94bmRXrP3oDHT/bB1N0ygN936FcXFkJqeddsV3DzoSzDKD7T6JWqyUi7vGkaWSkvKSFbC4PGVz44ceyizc7foYLrO07NNyk22sPpPylMwFxuAB9XCereOvN cXgK2RbH 2T3CPSQ6shJmd1fx+ieG3cxyQBXHfaqrDT0xQCocsYJaDruj7A/hfi+hjlaip70KQ3BJ9WmJaW9yYhX20sqUnnLMnbKxjg1wpySgR2j5Z+4fRgL9VngQD8hFKjHG2cTUHarP3f+vO+kjPQ/HhXTZFnYuW+e6O9FCrkyuvo0Nzqpn7jzhA8suHbEd/SvIJ1ir/YeCa 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 22/02/2024 10:20, David Hildenbrand wrote: > On 22.02.24 11:19, David Hildenbrand wrote: >> On 25.10.23 16:45, Ryan Roberts wrote: >>> As preparation for supporting small-sized THP in the swap-out path, >>> without first needing to split to order-0, Remove the CLUSTER_FLAG_HUGE, >>> which, when present, always implies PMD-sized THP, which is the same as >>> the cluster size. >>> >>> The only use of the flag was to determine whether a swap entry refers to >>> a single page or a PMD-sized THP in swap_page_trans_huge_swapped(). >>> Instead of relying on the flag, we now pass in nr_pages, which >>> originates from the folio's number of pages. This allows the logic to >>> work for folios of any order. >>> >>> The one snag is that one of the swap_page_trans_huge_swapped() call >>> sites does not have the folio. But it was only being called there to >>> avoid bothering to call __try_to_reclaim_swap() in some cases. >>> __try_to_reclaim_swap() gets the folio and (via some other functions) >>> calls swap_page_trans_huge_swapped(). So I've removed the problematic >>> call site and believe the new logic should be equivalent. >> >> That is the  __try_to_reclaim_swap() -> folio_free_swap() -> >> folio_swapped() -> swap_page_trans_huge_swapped() call chain I assume. >> >> The "difference" is that you will now (1) get another temporary >> reference on the folio and (2) (try)lock the folio every time you >> discard a single PTE of a (possibly) large THP. >> > > Thinking about it, your change will not only affect THP, but any call to > free_swap_and_cache(). > > Likely that's not what we want. :/ > Is folio_trylock() really that expensive given the code path is already locking multiple spinlocks, and I don't think we would expect the folio lock to be very contended? I guess filemap_get_folio() could be a bit more expensive, but again, is this really a deal-breaker? I'm just trying to refamiliarize myself with this series, but I think I ended up allocating a cluster per cpu per order. So one potential solution would be to turn the flag into a size and store it in the cluster info. (In fact I think I was doing that in an early version of this series - will have to look at why I got rid of that). Then we could avoid needing to figure out nr_pages from the folio.