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 C5014D10F5A for ; Mon, 18 Nov 2024 04:14:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2550B6B00BE; Sun, 17 Nov 2024 23:14:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 204556B00BF; Sun, 17 Nov 2024 23:14:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 055BF6B00C0; Sun, 17 Nov 2024 23:14:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D67FD6B00BE for ; Sun, 17 Nov 2024 23:14:27 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7F26D1C4A08 for ; Mon, 18 Nov 2024 04:14:27 +0000 (UTC) X-FDA: 82797897126.25.2B9BE8A Received: from mail-vk1-f182.google.com (mail-vk1-f182.google.com [209.85.221.182]) by imf30.hostedemail.com (Postfix) with ESMTP id 07A8080002 for ; Mon, 18 Nov 2024 04:12:53 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=deKiTXc0; spf=pass (imf30.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.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=1731903024; 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=PQd6JI85biFn4sbwYRSTbFK4J9rq3Xx1TpPMhTyPg5U=; b=E5T+QneblJRPUmZZuMPscEz4T3TsnlY6UFMCVLdaJJ+FszjxMsQNMXm7+2aXxUrn5Dagyt VG7szlOLRKKz54aJQF/cX3vpqn967trktt7QH6sxu2eGFboSSSnMv0EdsnGwpBYpp/+wuJ ueZ6BEyLu1Vu9u1K0quZ/Cjbzm+3Gpg= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=deKiTXc0; spf=pass (imf30.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.182 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731903024; a=rsa-sha256; cv=none; b=EAnL2WrYAHQMTKVzyfNv2j4lgGBMeCtxCKBWAAV9j6p2ZymQF5FEvkiA2W/D3LSowV6rtt YldznNDJtIpNjMVTjHNYZ3VKregs6hOtQb57BpJBx21wbPzDllPOYxy6oRT5C6efBJUh14 Tvcd7NNY3lwqDXo1WmuJMQJgeF+OPQ4= Received: by mail-vk1-f182.google.com with SMTP id 71dfb90a1353d-5146e6531c8so1180273e0c.0 for ; Sun, 17 Nov 2024 20:14:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731903265; x=1732508065; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PQd6JI85biFn4sbwYRSTbFK4J9rq3Xx1TpPMhTyPg5U=; b=deKiTXc0HIZYjWlz9JU1bPeUluvjQtV5YRd1wECRBIUg+MdOhogxvfh5zCaSDR3smV M5Fw7A/okybLNdFfXWBW1dcuB9Z4s3ScURrZ2Nl3gMxj/2ZI/vC+uW308eArePG/X3o/ HF5dqNgdwNqoG1fKuSSvMTRCUexb3Uzbr8Xx8FN++Z++sYREU9kdAE4uHB304UxCxAMv o1RhV/+46bMd5eeBU//OhIAYaLtMo//nLp8/oFuxaADqeIjhi+T1He2CT//qtBQMi5bD ui158pC6EjVZHJyuPkUWP2D8WaSh/khxqWNmEyGjSdAkpngqtsD6gfaTUfzG0zRrrFoE zgyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731903265; x=1732508065; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PQd6JI85biFn4sbwYRSTbFK4J9rq3Xx1TpPMhTyPg5U=; b=FGZt/OqUZJl3i5bKBgxiXc7J38xI7VuZ03mOv8UaUVxllDXmcI5yeH4+9A6a5D5KMu kLV7kHR7ymsj/wrZOc6TAj8kBbuFz6+h49vrbkD0CPNCs5fAOQPZ2kpNbAyDM2dfZ1CE ezi5Hm8M2uZ/LlRBJ5CUy1cIe9ifnBwxaRBikkt9dWSYgIdCO3hnlJ3peJ7TrvdX5/RZ jzUd2R3Yx4U3qz/RIlU48XRGkLQ6OQmirAg95r7zpihhZM8mcOYn+3/K4SP1wpLjQaUb 5lhhwgw38aIZZMKkFwyMegHnJl5xxuzx9o3Dv7V3xyFwUv2tZNue31l708srR9qF057b pqUw== X-Forwarded-Encrypted: i=1; AJvYcCWElMnt5XQCe7Urr93llntSs6VKjuWRDE3YA0nEpSlq4AeNxUX1W4BNcpsGM4L8hdHX1EynMmW8mw==@kvack.org X-Gm-Message-State: AOJu0Yyg0aoeE07xL2ZTgQV9kpVkplI65T5iS7yALdpeYJ8GY8/dNqdP cHrEfpIyy9fceoWvqAS3e0Ocruqr5xkjlgQQepqAsRnK+9pphfhwe74TI40wOTpwraXJR5BetN/ VDdxc9NDaxhReSgo6ljR5kGuTTqk= X-Google-Smtp-Source: AGHT+IFqn2Ag9Be1EYUtk0qbTon2Pz8J3bvBTLUBi2O1zIWfzTGRnArJmiRDqhI/HtuXrT/KxPYCGy0djt2J4gohTic= X-Received: by 2002:a05:6122:789:b0:50d:85c8:af3e with SMTP id 71dfb90a1353d-51477eeb37dmr9177343e0c.3.1731903264820; Sun, 17 Nov 2024 20:14:24 -0800 (PST) MIME-Version: 1.0 References: <20241116091658.1983491-1-chenridong@huaweicloud.com> <20241116091658.1983491-2-chenridong@huaweicloud.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Mon, 18 Nov 2024 17:14:14 +1300 Message-ID: Subject: Re: [RFC PATCH v2 1/1] mm/vmscan: move the written-back folios to the tail of LRU after shrinking To: Matthew Wilcox Cc: Chen Ridong , akpm@linux-foundation.org, mhocko@suse.com, hannes@cmpxchg.org, yosryahmed@google.com, yuzhao@google.com, david@redhat.com, ryan.roberts@arm.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, chenridong@huawei.com, wangweiyang2@huawei.com, xieym_ict@hotmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 07A8080002 X-Stat-Signature: z1zhowdrosehizdbcf6bwo5uujb73m1w X-Rspam-User: X-HE-Tag: 1731903173-114358 X-HE-Meta: U2FsdGVkX1+ncBxLgEe0JirR2uM386DcPcn2nNwBlRpfeNfdsKuhoXnBbc7UHgEQR7K/fNsvFRAzuLSKaJyYlaVJWrGZfNJ1m77OmR4kaNMqlUBy5UUamOkTDPrLj81lPsw8w5/hFXG3ZDlgzaY8TAtfN3AI00GOqpx9SUNm/Nso4F0zBhn0E0Tpe8F6xE9soNnwsuJeouLHFHZwIzuBnKCrjWB0E/WLPV5Jfc7LenfCVwBIc0urJp4gOZOXmqC5PGCEXkTGL7i0gHHGQ2uBz+jd0qBgpLThOX6UpmiginshdPm8DHVrfu9aHAjO0EnNJiJTmMBfzdW50hcQfXYMKQajykiq8jaHwAcnXFFMDkokPBRi33zJGgFG7Vqi7m1JBFjokGiEvLpO2g+gHSZcq9DLcbov40kNDa+mffKIY7qxgK3+o1mQXPsWAs0SYNLp98b0txAR9kICODfpW/ejGbrh7Ydua3v8FJznHnX7ev65zzUZgsaN7fY3OidIGGQjih6lyT+Ro9N0xjZ6L4lV5wi2TCzYmRXduPAATvPUbqsLle+9etw4i5V5pWkbOpmKrUkvrE3ZlEaKN3gObjvhxWx+B7E3TQhNlaxhuyNVHGzQZAQOdfoNPnOVVEZZcg9DZbxHZqOaKbPRx7F4mdRdtq3+c7yiJfbOxHPaR+KgL55jkcBi/njFpYTOmJuZ+riOoXqq3QX/ojQciFn84ssHqW6+DjvaSB5JIGCKMpdJvh9jzi8NdusjXCDwcLYiM9sKPxZ9NBwtnyVBFAFXJs5lX39Xxc0ThIEFtbVu99kVhkPy6rPwSBYAMXGJAEFzdnbCD6INhbGsdCRB/TZfY5cOgEgyhMEvL//sFfkPMBjPu+rdXU6lJIQSsNg0w+BND/R+WBloSIs7P/lTfiTcUvOODsPaLtyazQY2Yxkl5JQpCPRb8pEL8yaHc2HDWg82wnwPbecePOXM4bATy/UKx7Y SuFCj3BZ ln9g9KbSxqGu5YXoWXXy9C+Lh4dD7uHEKsJtE1W3fUh0Rcdal5cAYocDWzdHLHxT+oN6Dm8WwIyU52CGiNYrbwTKpP4G4Fst7dbHLSwVyhwIBaWmML5ecJjRDqn6AgzHSCFw633BAoi1/AWOQK1cXH39K4fzAnedx2hj2iizGUXbLkFe2TnSXvksTLVyT2RlK91FK6ZUyo1V9nQqDhHS41SqHejDioJ77UYlf19H+vs1lg4Q6OE+S2bfBfyBZNPHZk7EppFolOjp4+MEpVOnoIfWxXtuXLJGKxid36Wccawfz+33pj49/EWMEE9LIeGrNBsU6kq1dJ2aynms8trDc3gUEKeLAFVvJt1J0IQtkNlkRfbL2DA68RAuv1631u+egUmjl X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 Mon, Nov 18, 2024 at 5:03=E2=80=AFPM Matthew Wilcox wrote: > > On Sat, Nov 16, 2024 at 09:16:58AM +0000, Chen Ridong wrote: > > 2. In shrink_page_list function, if folioN is THP(2M), it may be splite= d > > and added to swap cache folio by folio. After adding to swap cache, > > it will submit io to writeback folio to swap, which is asynchronous. > > When shrink_page_list is finished, the isolated folios list will be > > moved back to the head of inactive lru. The inactive lru may just lo= ok > > like this, with 512 filioes have been move to the head of inactive l= ru. > > I was hoping that we'd be able to stop splitting the folio when adding > to the swap cache. Ideally. we'd add the whole 2MB and write it back > as a single unit. This is already the case: adding to the swapcache doesn=E2=80=99t require s= plitting THPs, but failing to allocate 2MB of contiguous swap slots will. > > This is going to become much more important with memdescs. We'd have to > allocate 512 struct folios to do this, which would be about 10 4kB pages, > and if we're trying to swap out memory, we're probably low on memory. > > So I don't like this solution you have at all because it doesn't help us > get to the solution we're going to need in about a year's time. > Ridong might need to clarify why this splitting is occurring. If it=E2=80= =99s due to the failure to allocate swap slots, we still need a solution to address it. Thanks Barry