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 17080C4332F for ; Sat, 4 Nov 2023 05:50:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2263F44014C; Sat, 4 Nov 2023 01:50:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D6558D000C; Sat, 4 Nov 2023 01:50:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0781D44014C; Sat, 4 Nov 2023 01:50:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id ECEBC8D000C for ; Sat, 4 Nov 2023 01:50:05 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CC4BBB5B47 for ; Sat, 4 Nov 2023 05:50:05 +0000 (UTC) X-FDA: 81419195970.11.7420D94 Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by imf05.hostedemail.com (Postfix) with ESMTP id F0C3310000A for ; Sat, 4 Nov 2023 05:50:03 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TEwO6eam; spf=pass (imf05.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.210.182 as permitted sender) smtp.mailfrom=21cnbao@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=1699077004; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=kGamaTaWKR3LhrtF+DQPbS8E7DjUl3cEVZSu36pwK8g=; b=vVbVL+vr+estavOPVuKRqEXTTISYvyoVk72fxg+XJcj21CKsFj3VfbUNXxoGOmvWqJ8QU4 WRor/RkPClovrwIvSehIOlrFAtFlbAqsByWupiE54r3sY/xRAONf5It9sCQP3V4+YAMVrg Gc6SxQtfBPnS6RY4UllvOLFDjoWVsHY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699077004; a=rsa-sha256; cv=none; b=Rla8QRpztQjFs4rbFY8aO2hBAski8/xflz1lC/REsl0kSSeCYEs9EsbvmXzV44Gd8S8+ae sQLRjP6gnQ+mo6jv+es3oun7zLfOS1aeI77zMIQCfNPyBtSZWho6vYaRoKhXI+VbjwM/Tm 7nYw+txwgac5V4QBjBZzpf5ZDWuIOJA= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TEwO6eam; spf=pass (imf05.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.210.182 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pf1-f182.google.com with SMTP id d2e1a72fcca58-6b2018a11efso2916811b3a.0 for ; Fri, 03 Nov 2023 22:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699077003; x=1699681803; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=kGamaTaWKR3LhrtF+DQPbS8E7DjUl3cEVZSu36pwK8g=; b=TEwO6eam5IngM3lCWqC0FPXR21X4FESrseU1j6LTs8v2bNkllQOMtcZGr9i2tQS1TA ztkc2oXtbzAlF9SlkZV/gOHV1broFmru15xhx+FM+o1Ok/OwmShGMWEsSldDa2jYn5V5 +I2DOP7yO1xGwg+GNyhheDoF1DQuDshMG4uEBXP2fcvdwb/LsD9h4Vs+704f0/kGwmyl j3DPA+xAMMa/Exwa1Js33K4fYemtic3TNI5Y7YuaEePi0t+4DQ2N8bkntXIbQc/fUa2b OQlpTQcLqsr+2RuQ7fSVH0Cdj1KRr5a9N4dn2DkE0TBcqjhMX9vgfH1/MdQWchxjK5Pu XV9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699077003; x=1699681803; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kGamaTaWKR3LhrtF+DQPbS8E7DjUl3cEVZSu36pwK8g=; b=o68FZXR717H8FR8SOmEic5XlnJKzzRloW9AG+Lm9kBGmj7ssWMePI+TAiCickeDzVT YlITc8g0AVaIZ8dtELDsd6W272surBnxjoZGskcoSydD37+L7mPfssf5ulJNwlW2O449 zxPBUXyCx9ik0Ppv1tbNy4SqtNFY6ML+nwaZurjn6wgoLvbX8+7UG2Hbq/lE1IXiOliW xXYXXRib4GFvO8FmgTrVPDKbDJJ8pQc4nbQr8WIr094AXcpzAphFcPLxlSR8sQcJHBeS 7CLcsQGaWCiUf5ITOm93lwMBHxjLrTuzdklzKCjAyQL/EojRd7ND33xkAR0WfFv3ltfc NDTw== X-Gm-Message-State: AOJu0YzBUYgUbHl+3DsZIudTbE3qM27iWOqoLDVIkYexHqNUZwe8Ykzm D78l0RJd96xq5oWAML3nDVU= X-Google-Smtp-Source: AGHT+IGSsHQd6OPJXfEWVa0wuVqgmRAWAqLLnQcZbq4nJetfFsHgoauxpapaaxmuxugII6Ef0056Xw== X-Received: by 2002:a05:6a00:248b:b0:6be:130a:22a0 with SMTP id c11-20020a056a00248b00b006be130a22a0mr28381293pfv.14.1699077002624; Fri, 03 Nov 2023 22:50:02 -0700 (PDT) Received: from barry-desktop.hub ([2407:7000:8942:5500:4e57:64bd:534a:1d8d]) by smtp.gmail.com with ESMTPSA id h7-20020a62b407000000b0069323619f69sm2296275pfn.143.2023.11.03.22.49.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Nov 2023 22:50:02 -0700 (PDT) From: Barry Song <21cnbao@gmail.com> X-Google-Original-From: Barry Song To: ryan.roberts@arm.com Cc: 21cnbao@gmail.com, Steven.Price@arm.com, akpm@linux-foundation.org, david@redhat.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@suse.com, shy828301@gmail.com, wangkefeng.wang@huawei.com, willy@infradead.org, xiang@kernel.org, ying.huang@intel.com, yuzhao@google.com Subject: Re: [PATCH v3 4/4] mm: swap: Swap-out small-sized THP without splitting Date: Sat, 4 Nov 2023 18:49:40 +1300 Message-Id: <20231104054940.8971-1-v-songbaohua@oppo.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <6641a14b-e3fb-4e9e-bb95-b0306827294b@arm.com> References: <6641a14b-e3fb-4e9e-bb95-b0306827294b@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: sy6zskbr7f3maiz5tcuyb8dr45dosm58 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: F0C3310000A X-Rspam-User: X-HE-Tag: 1699077003-9419 X-HE-Meta: U2FsdGVkX18Elc76jHp4v2D9+WGfCkuGw0nRjf2TOmU9dHnWnebYQW06Zm2h3SMN5ymVFypcXMd6YrxiRsTOnRxo+ADLw1M0chyo/ok/WD9o9/HUOQKVc0kbXKEHXnhFcpx0HjiKr20CM78OMIP+K/uA5GpTmQmhPc1qmqmkB9Z4oz67i5c70ytHq7P1f6EiLV85jNiNrI7ktImmVVjCSLxMelE30CnVytHQzk876m7IUOm8npCeLJlyV5b7/fwtPbe5lHJKVli+GzgYUWGny0CwyBn+yWDM8CP1UF+5MgN6zt+7iR3+VGO6MEhTyDkrYiKFxRCsmJNjLjeA2kCsZTydoS8dqeReCplmScIi+KkPaC1h3Cqk6pgoEAZuuwiqGLDzptzLaAWdIwRDA99ZcMosBvMglEQM/95kCjzAzgyKxwHsxMl/s92fMGfoi/EmQDdVetbf26DUVq5oT0UytRB6h5M6XWn0vD5wXtNpolTfEgbIFRLHtv80dNlQEvEbvUIDXfVbYqA72bVyH6atK33uQiSxYBtH0Up3oQ4OAFcktfpR09mSne7ZpUPjTuHl4BISKmsPA5uV9GKmIgSAYGJYnwG0SVMxitLjLSYtCZbFXRAai3hJiKjRGf0xGPCAc9Qs9TswaYtVmzzqsS/ZsAcm2hPxDBz6WWkbTP85XwbgzQZEb+JWuZ7ggv7DC3eiPoOTtzp7OUyop7cXbrtbXenxCytYFswPKaM8ARNlzGflDfH3vLIk4bacI+jpO0vjzZ7RBtR5w5EbusdLm1J1Si9/8H1V2Cd6vO+k9cy4SGT5euDaH193BarfPbkN3UQiktNYxb9QXBB65qwbB1vNzoqBoWhqic5nvEednwE3TVOBjvaxLrKRfMB0dalsD1C2jWj4k750Ip5hZiqmusgHBFRWG1iam2k8wOHYB3+DpRTCYjiyJ3rTt0er6DTsBOEG15AbSBmOkZ7F5OqtM99 c2hPK7Pw pPotSymbYX7c7of+6EYEosqke10g+I2+fhkhIRxzv55obl6UYh9TbxHpO1t0CccvL0A5iFXPbAPi8C2EY439aTZ1cluvu3ZeaxLYXXZashgcMbjxdBjag7njCABFg/lNU2I4QpG7u+ZnbZHmF7RRbeZRNFaqe1o+YhqG+LQsHU5BoIvIg1wQtMwJbJEwZNndN2o02g/qY12U9EU/r8neBEeKQDMwJE6pbyflgDvgVcqlSEns2a4N99BzM/T4FiQ624aNSd6kNOx7VsIEE7yEZSeTm1Lbi9gyFWumrmJGxyqXTslwch+JvGrKUgXY61YGsPhDVK2QI5ZzSK3MotVDsbFaF8YtiLWn8pcIORQPm/v6uwmR5Zsjo1uiu/NZ3VjkG7ig6p+4ykWUI/mA= 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: >> #define __HAVE_ARCH_PREPARE_TO_SWAP >> -static inline int arch_prepare_to_swap(struct page *page) >> -{ >> - if (system_supports_mte()) >> - return mte_save_tags(page); >> - return 0; >> -} >> +#define arch_prepare_to_swap arch_prepare_to_swap >> +extern int arch_prepare_to_swap(struct page *page); > > I think it would be better to modify this API to take a folio explicitly. The > caller already has the folio. agree. that was actually what i thought I should change while making this rfc, though i didn't do it. >> +int arch_prepare_to_swap(struct page *page) >> +{ >> + if (system_supports_mte()) { >> + struct folio *folio = page_folio(page); >> + long i, nr = folio_nr_pages(folio); >> + for (i = 0; i < nr; i++) >> + return mte_save_tags(folio_page(folio, i)); > > This will return after saving the first page of the folio! You will need to add > each page in a loop, and if you get an error at any point, you will need to > remove the pages that you already added successfully, by calling > arch_swap_invalidate_page() as far as I can see. Steven can you confirm? right. oops... > >> + } >> + return 0; >> +} >> + >> +void arch_swap_restore(swp_entry_t entry, struct folio *folio) >> +{ >> + if (system_supports_mte()) { >> + long i, nr = folio_nr_pages(folio); >> + for (i = 0; i < nr; i++) >> + mte_restore_tags(entry, folio_page(folio, i)); > > swap-in currently doesn't support large folios - everything is a single page > folio. So this isn't technically needed. But from the API POV, it seems > reasonable to make this change - except your implementation is broken. You are > currently setting every page in the folio to use the same tags as the first > page. You need to increment the swap entry for each page. one case is that we have a chance to "swapin" a folio which is still in swapcache and hasn't been dropped yet. i mean the process's ptes have been swap entry, but the large folio is still in swapcache. in this case, we will hit the swapcache while swapping in, thus we are handling a large folio. in this case, it seems we are restoring tags multiple times? i mean, if large folio has 16 basepages, for each page fault of each base page, we are restoring a large folio, then for 16 page faults, we are duplicating the restore. any thought to handle this situation? should we move arch_swap_restore() to take page rather than folio since swapin only supports basepage at this moment. > Thanks, > Ryan Thanks Barry