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 B5E70D10F5A for ; Mon, 18 Nov 2024 04:22:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 25BD16B00B9; Sun, 17 Nov 2024 23:22:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 20D1B6B00BB; Sun, 17 Nov 2024 23:22:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0AD746B00BC; Sun, 17 Nov 2024 23:22:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E0F746B00B9 for ; Sun, 17 Nov 2024 23:22:04 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 60ABFABF4C for ; Mon, 18 Nov 2024 04:22:04 +0000 (UTC) X-FDA: 82797917286.11.238969E Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf16.hostedemail.com (Postfix) with ESMTP id 52930180006 for ; Mon, 18 Nov 2024 04:21:14 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="TtHZ2x/Y"; dmarc=none; spf=none (imf16.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731903540; a=rsa-sha256; cv=none; b=dLGGrcO0ARcZApmXjiVdEL1TwFlqyZgTY0yNGTek0hv0jT2igONt/hzpVr3aLWv42Jy4ly vuFd2JcuniukSr9nbr5F0ea010EUg1KWuEWOjyivA2wnNb1WV5NV0LHCSSGuX3+9t2ZjpC I4W3yHc23S38oocDuvWc43r1qqRxGqY= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="TtHZ2x/Y"; dmarc=none; spf=none (imf16.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731903540; 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=aYkkJ/xn2nCKMiiN7tsl34G8O8kOQEIySBtfq+iOWXs=; b=2qiVpWcT3VDgp7/JckT9RtT6Kc42aVrPOxz/jI9QWwe/76uU5baPRaF5t0qe1oCtSUm516 1dEwEKO4n08Z2yHn5EulXVgg1m+Sr9Vebv55RAj+GM559xo/HgBXdQDWeobu2S/axhoXzH h3L7P/l+RwUFkyUbheDpsT0vhakUUfw= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=aYkkJ/xn2nCKMiiN7tsl34G8O8kOQEIySBtfq+iOWXs=; b=TtHZ2x/YJ0TkFRSHg5PYv3oeUd TfEcQOG8Wzov63HCuTIuLhyEZZ9iJS9uuckMF5GUy3HD5O4nFBZL/y/vWFSt5nLInhBiMFkokT18H 5mMlDsCscA2asfm7Deo6gBLyr6lFqVyr5Kpk52Bhe29yRehhDHfmtoM6y/0SrmEQ98xPRAxyR5eg/ L/PFGXf1TvX+/f4NnJkc69HodS7OBn3HNdN9qkkvQ1s06C/ftmN8UEGkbydTqEHj8UXovIx+xq0qZ wjMMApP8ZzmZ6WHc8PLjySSaLmX3jzLrR82nU5o5ZBiA+eLICR9bSBZHyPJrr9oCZQhaWG1PM4ByV kWQZPdMQ==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tCtGw-00000002YtG-2u92; Mon, 18 Nov 2024 04:21:58 +0000 Date: Mon, 18 Nov 2024 04:21:58 +0000 From: Matthew Wilcox To: Barry Song <21cnbao@gmail.com> 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, Chris Li Subject: Re: [RFC PATCH v2 1/1] mm/vmscan: move the written-back folios to the tail of LRU after shrinking Message-ID: References: <20241116091658.1983491-1-chenridong@huaweicloud.com> <20241116091658.1983491-2-chenridong@huaweicloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: r8hba9tdqbwpxseqg63aiir6qeho1xtm X-Rspamd-Queue-Id: 52930180006 X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1731903674-854256 X-HE-Meta: U2FsdGVkX18m5QvEgmIVkTGO5s+W+oN/voYdt8cYbRSkcXj7piWsxB2Vp76YlKJBdFMP+KCon2Z68I0jpQWsbOKc5Gv+a3frio3Z3sOt4CyFDaIzB+JKEevQ0KuaFEdc2mHWddBh0e5Frfzd6O1roLStbMZCh/ExyAELbhFYelJAoRTcFXPdruEYFRFhKft5ayq8+u6Lg7eMq40CaMstB3V92DWR5snzpW4xSbEf6o0te5OxJbHbLCLnX/kuuEFOhpotvfbG79aSMKx0gz45XycHyVi2nmdFjKp4JiysKVgTnh6Coykg1Z9VO6oef0roIXg3kA/89DJxg2B6rDRcFRAgeQPEpQzBZ0hwF8MT1LqsmpasT6fGnHFkFZjIJbGa1JzaLy3JkueuZkI+UnheOUrB2d47qC40o/JnE2hXqeXSnnc10+e8arJqu3/aJuOlMwVN6t3ixEBCkRTjJzhIpMZFl4BYdoaq8z9Fz9gTt5fJyRD89TI8VYAwySIoM5mEqD9M7DBjw6K2bx3rRMqGYDxXd43YA63A4ftXHV5zV3kyohuK2f/xRDt5MN7Ep2D/x4bkvCxeae1Nt20bGEi8b1l2WFOspgJrtVZTwKMg7DLgYDX0H/7M9HXZo6IMUtkMfMLnxV5qM5hgA8DQnVrITNwAgoQ24DKcYcoMKh/A+cau30OBtyfsZGfafvEk86MY1C2+8Q8M/qEE+zVOA7Ismitci80dJkvicisRYB8DoVUbrZrJlp95aJKNxj1VOMJaU6zGna/s/xWo/mVFl8SVJhBiRS9XXK3zpGFuQvbqCoB4wkWh87RFvQy4TuEMeMolCWGOOMt76Z7Js0HSZ7HYWdcPTOhSNThBXEzuYvyl6yHmcx1+dhnHPc4a86NZ0+ugXZEjR+WQmvKVgpaNv9Kp3X0w33jrAMEGxvFcEPmUf7wjm1KW6RxMlMwvDgKUki3day8UtdbqBJFs1ukrslr a+ljn3bM 0R2jHYdg+NmjtAF58pwAGAsWxnv8rfax0yjd0siBqK2hfMPz1I9/hFXnKlJH/ggPqpeZwuOlYe9RnVOzdTLQh6LXT736t0YVI4bG4VTe+vShSKlgngXaTv3VAmkmzLOGCzDtxsA6acudNU+PInhWT4isCa+WayiNpF215G/92d+FkeXPIXEA6Or/3pMkjK5w5zXfOEKLkhqOYOAfy1g6Wh/ok076gEMS69Z3rirV/qRT7+xxSPnEQqnPqFNatkZawCtf93vwcsTa2FQy4XB+Kib/q0vIWqtLM7z0qXXjpMlsBO4s1RFi5sby39+3I0fHbuVYg 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 Mon, Nov 18, 2024 at 05:14:14PM +1300, Barry Song wrote: > On Mon, Nov 18, 2024 at 5:03 PM 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 splited > > > 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 look > > > like this, with 512 filioes have been move to the head of inactive lru. > > > > 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’t require splitting > THPs, but failing to allocate 2MB of contiguous swap slots will. Agreed we need to understand why this is happening. As I've said a few times now, we need to stop requiring contiguity. Real filesystems don't need the contiguity (they become less efficient, but they can scatter a single 2MB folio to multiple places). Maybe Chris has a solution to this in the works?