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 8A7E3C52D7D for ; Fri, 16 Aug 2024 21:17:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 048076B03BB; Fri, 16 Aug 2024 17:17:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F3A656B03BC; Fri, 16 Aug 2024 17:17:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E28B76B03BD; Fri, 16 Aug 2024 17:17:20 -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 C6F7B6B03BB for ; Fri, 16 Aug 2024 17:17:20 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3B00840333 for ; Fri, 16 Aug 2024 21:17:20 +0000 (UTC) X-FDA: 82459369440.16.2275183 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf02.hostedemail.com (Postfix) with ESMTP id D112980023 for ; Fri, 16 Aug 2024 21:17:17 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=QOtK3PIl; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723842963; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=rS71YMLfit1EALalhCPrRhHSkDiUzIHUeAnRBQ5Q7xY=; b=tEEFoZFmJalUXSaoYt1pfwBNNg95HKO6TWYtrBU4s8rYOjtJgi3wLuxwj12pWFaXRw6rte vmglCqbuJZAM3sybK7ogm5DDh/mHr4oj/qL1bd8a3ejSQgmubv0sAd5pG+G1TUH2pYDFsk rs7tMBV7XWq6cHZNLYTdwZ1nHfz6Kug= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723842963; a=rsa-sha256; cv=none; b=Zl0W/rWitwIes8G9A3Com1aP37UnjaPlinrC0GVp2YdA501VPQVBep2KfObLW/dILJX6jF npstblZ09RCeyrIHviqI4Wyn/hGHYBLtm+LlmLLsTAGpHRMqQHOgQn4rsBneiRkfGd9+gp NZ3vJwzfkJ+ayMkHCOAY0FErMPW4H0E= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=QOtK3PIl; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=rS71YMLfit1EALalhCPrRhHSkDiUzIHUeAnRBQ5Q7xY=; b=QOtK3PIl6AMduVJvAJEly2uwQo yUACaryvdl15PuzQkXkyHUBTKUjQbhdAbiS+x0mccotcDPs8BcUu5jS/Mf/5IYTqGE1cby6DgT5kL 5lRkT9ziMptjwEwRSId95vobvlBM4nj54bxmTm7vJiAK4mxv2GTCsE44p8WyKH2YFw5qU5qqIiBlY YCW6CUnIyeSYAUg6CxYWd52T88OQKCc+MA8/2d5hWQl6Hn2sXixBW42jO9pBODYNL7/uuO4xdRv5G RrM7cLsfbhiXh/yWV5C8WCGGJYFp6aBJEgfzdQ3pr68Kkd1sQ2eOO34oJnwAyq2tRN1bhtsJOrMvZ 0SUolidw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sf4Jd-000000047E2-3hIW; Fri, 16 Aug 2024 21:16:57 +0000 Date: Fri, 16 Aug 2024 22:16:57 +0100 From: Matthew Wilcox To: Barry Song <21cnbao@gmail.com> Cc: wangkefeng.wang@huawei.com, akpm@linux-foundation.org, baolin.wang@linux.alibaba.com, chrisl@kernel.org, david@redhat.com, hanchuanhua@oppo.com, hannes@cmpxchg.org, hch@infradead.org, hughd@google.com, kaleshsingh@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@suse.com, minchan@kernel.org, nphamcs@gmail.com, ryan.roberts@arm.com, ryncsn@gmail.com, senozhatsky@chromium.org, shakeel.butt@linux.dev, shy828301@gmail.com, surenb@google.com, v-songbaohua@oppo.com, xiang@kernel.org, ying.huang@intel.com, yosryahmed@google.com Subject: Re: [PATCH v6 2/2] mm: support large folios swap-in for zRAM-like devices Message-ID: References: <20ed69ad-5dad-446b-9f01-86ad8b1c67fa@huawei.com> <20240815230612.77266-1-21cnbao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240815230612.77266-1-21cnbao@gmail.com> X-Stat-Signature: zhgbr5twqu4fbjzuqwfm988zmsbsbmra X-Rspamd-Queue-Id: D112980023 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1723843037-647338 X-HE-Meta: U2FsdGVkX1+sazjWW3pYeSmc5FDs/F673h9z4Wp/6eOxleCrER7EfCjIcHo7L8CQjaSytq/nhC26e88xF7RWIxyajoKp/dh8RTgZe0SaKJ4I8IqGoBUG1wAfPgi4HEZjYkASPFQA3bOsywAsZFW2HmTLedcGjjizuXGZTgKtW9c6rE5sDdo3n5hckjVunsF5Qal5y1kL+roim/+lzWkn/2Co75XCxjGLQ5Af63jwiBzgYbL1gubv0Y0UE2WGSbizsalq9CzumbVshd5iwOg7tgP6qiCV9qNwfJKvknxwAd3gfR8/nbP1HAPPXMoj1KrI0qk1awIaAm3lrsCDN7TaHwsarpKTwsYafZIHLErxNBccMwgIlxBLmCECjowDAD2pudCYKXoYeXSPsS29MqHLXVmr8SqQavwpcaFWyDGt3ReaDwqplDoHcz+lw+yQ15Hpm3QYMXk6MpaI+FHDTkTleScSiN+BHOqqxbRpnHpuSRC5qGAzDGQmWG4ZLdeMkdB/xQenDNLQEv5guFAmUUslf2uBU/uf6AiRO24O4Ef4BKnoJT5Bi7gWX6C1eB9lFKHGxHBnHtJ1q3nVminrTJJ5jCPUCpiPUcjDbphbno56k8VPq4cDK0aoXaV9HJOKWPulWd3GDEbPWz9ThV/7htiuqlArUmVSINswhQMviOElm/umB6OhYoxxkAT1JXOey0pXxQ5hMR4zbzjepbQa2RPG07aOevr+0diUOOK6Z9AKRj+upvw59KHEmXX3pXiTA6flHyUZPhPW5erg+so4yyKgyCqLClhzpyF8wdshrExoFRxAkdrQ1SgfhANfssnMbEbghPscoILp3YMT04qMtErR9aiiqhGZtYjI66clKV9dZ8ZIDNJwJbYv9AxLVmZM67tZfANKceh6foquLcjlpQbG7hgGHmLppNYS8D42Z5dmope5tktTHs7HxxAH3yORLtl+uBn5YU598euz9z+2UTP kxfefSiV wHKsFJhpkN8Hleyjy0vbZBIh0Qc3d9wQm6jUtUV2UY5mo+YYjpBvnXQcW18OjPRCwcLO9vxGNSY26s/Zyq8KHK3jpnolDNW4deGRjj+sGE/sudtg2twtmQKvMKeLGRHqkd2AhwlzkmSIsfPei+V3FQ05b+B8JjY/xdXAM3xlOZ8EBO2yxHXI14rClLJVMzfZyy6bnuDssr4oEjwMfFLxGDbr7kJ0S7GW3zcxxaqFoJka/Ws4= 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 Fri, Aug 16, 2024 at 11:06:12AM +1200, Barry Song wrote: > When memcg approaches its limit, charging mTHP becomes difficult. > At this point, when the charge fails, we fallback to the next order > to avoid repeatedly retrying larger orders. Why do you always find the ugliest possible solution to a problem? > @@ -4244,7 +4248,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > } > need_clear_cache = true; > > - if (mem_cgroup_swapin_charge_folio(folio, > + if (nr_pages == 1 && mem_cgroup_swapin_charge_folio(folio, > vma->vm_mm, GFP_KERNEL, > entry)) { > ret = VM_FAULT_OOM; Just make alloc_swap_folio() always charge the folio, even for order-0. And you'll have to uncharge it in the swapcache_prepare() failure case.