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 2FE68C3DA61 for ; Mon, 29 Jul 2024 15:13:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 454FC6B0088; Mon, 29 Jul 2024 11:13:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3DDE96B0089; Mon, 29 Jul 2024 11:13:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 289EA6B008A; Mon, 29 Jul 2024 11:13:46 -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 088DB6B0088 for ; Mon, 29 Jul 2024 11:13:46 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 85B5416042F for ; Mon, 29 Jul 2024 15:13:45 +0000 (UTC) X-FDA: 82393134810.19.50F2451 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf16.hostedemail.com (Postfix) with ESMTP id 9B598180026 for ; Mon, 29 Jul 2024 15:13:41 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=CnIwwmfG; 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=1722265984; a=rsa-sha256; cv=none; b=ID2Scq2Dl+zHUjc/uXjT2sWQ+NZgSmhGL4oBZ0KlNi3m0VA4yF7lCElj/0f8aePUbEtZKs fx64sm5D1XGqRucVbhpccCLdB3bs2m5/2dfqymj0mrMWNYfv068vPj+XVf6ZO+uivYFB4C TFcsMohAS/0qbkfBaDgPR3WAnC8pu5k= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=CnIwwmfG; 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=1722265984; 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=OfSA4+9/J6ynfT9ZfDkV87nJ93qqwf5Oh6tfXnWAcpY=; b=mcMKpGVj5ZRvlCht1djxh7hO6dGisrAJFORkL/4WCsAK+wr+4EfrINTxrYhx4OYu2LeQd5 0SaVua6oX0sf9784uGvXF5/FaEfoaEB6ghAeE1D0YqEnP6Ob/sL6i8i7un7dDiiuo/zEE2 Bp9fY3dSNa1pOFQSqqSSywOqexUI0jE= 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=OfSA4+9/J6ynfT9ZfDkV87nJ93qqwf5Oh6tfXnWAcpY=; b=CnIwwmfG5LggerkaIWlhBj959l WhcYzovUSNzfIc8144IbeWoDghRSwlF2BfN37UP2mH1phbwyFbsBbszTY7MocEts6cNgPbXRez/fy 1+FdGowgrrW3KhxuYwG2/EMsa0QQXgkoWl2oJ0ViItbP28ckR7FyXyk7n9DuyXI2dc5sTGQQLsgQk Qf8TL0/UATYFv12+IJ+tnZxWrieH0h27TqGmI0tqzeCNZq6PqI5Ol/s2oyDAnfR5QWBO16+SvUh4+ mzUvV4o78rPjE1zEaMVGO+xF7epvtlDccTKHzF98ogqwBt/mvzBzWUX3lGv2sJh5XPhA+8zUfLBPZ yO15UZ+A==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sYS40-0000000DheT-3lMm; Mon, 29 Jul 2024 15:13:28 +0000 Date: Mon, 29 Jul 2024 16:13:28 +0100 From: Matthew Wilcox To: Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, linux-mm@kvack.org, ying.huang@intel.com, baolin.wang@linux.alibaba.com, chrisl@kernel.org, david@redhat.com, hannes@cmpxchg.org, hughd@google.com, kaleshsingh@google.com, kasong@tencent.com, linux-kernel@vger.kernel.org, mhocko@suse.com, minchan@kernel.org, nphamcs@gmail.com, ryan.roberts@arm.com, senozhatsky@chromium.org, shakeel.butt@linux.dev, shy828301@gmail.com, surenb@google.com, v-songbaohua@oppo.com, xiang@kernel.org, yosryahmed@google.com, Chuanhua Han Subject: Re: [PATCH v5 3/4] mm: support large folios swapin as a whole for zRAM-like swapfile Message-ID: References: <20240726094618.401593-1-21cnbao@gmail.com> <20240726094618.401593-4-21cnbao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 9B598180026 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 6ps9hbo1wb48pic7sx1pqz6pgga7uect X-HE-Tag: 1722266021-177003 X-HE-Meta: U2FsdGVkX1/ubdTg3lONLJ12hGfrEIaidnRvpWnRpRMJo2umMknRQmjcx34nUWzdeWQ2ZJ7X3AQl0KM3Yh1VasmS34v6tJP4iy/JsjNw7ZmBRrQi2C3eZptBu8lE13m3wxsxn8bW+MOcjV8a2RtGtjU4+Q2k8FgPyqj3EqvWVYCFHoS0wVelSYjNKgHRKWoGqRLbN7L5qlt5JQ5eQPLF6M8jh4ZT63joMn+d2GFk7mZQuPAFWf+03+4Fe7ikaj4daNL7spxdfOiZlq2hVG61ICiS1t6OagYJZV0BZINFD6gYpriQjGO9xSs7dGvN0YhZudKYVrijNFC57fv0cH6OgoAY060fQwmaVw/CHF5JlYQ3KKVSx2GD89l6vhmkGQZ+3h1ueaqgw96hDJ8XgZy0pr+4S33eRCd5Zn7kdAiVydRPt1W3Kn6f2T/5UulzLUQuhIaj7AO7zStBBBTxWIva4JPe36nCylWzl+A+tib9g/5ttIjM/7dxQ7tKDTo49sX8CWNrntB2nqjJw+n8SNeyELFJ5tS9LIx/gaPOeZ08gvlKbjRuiIMG57SVgCaK+qBmmxObMikKU7wbjruZ1dkryiPlZ08+3qO3bmNcAKkxx6M+lOstZ35wh8dAe0jyO1S5DPhclzaTLX6aLsNWoR3z6LB6SFQeBOSpMCKLaTpxXQrnWtrZHnhdvqS58kf+0elzutGtkXQS+GA3ZsrDM3dHKyrN4AwKae/qRgDF6E9/EV9VHLsXJYVoJsOr805+Q18ZcjIBTh3MmRwFgQO3eSz139m2d+QADNUYHF255+TjAnSctnGavKLB3u8+cs/DycfFt3wEN3ZpFdzOnp12VYzqEg2JMoYDoIHVKreY+R1hjOFgbQr9qP7Vto2o3WrPP89XqKsATHPDekvIsnpDeY3MozLHdPsTMbeI9wCmKxPL4gH8dlptRUYnia87MCgyH0C+ccIkLMsdz3o7hA8PMb2 zcQM2bN6 U7wFihqJdU5E3dcYuDMtnLVlC2behpavcAn9h5mzJi6rUiSm/5f4Hwo5K363F0eBiNTGICQaxAYklrDIu4roU5pAyDL8tLt50URLwuMxdOGB0qXMSgUICoE+1gfHnAS/6mgAwe71SgsG6Y8JAMPQPh3zt4PipIVod4a+rf2Yy3zegfRLhTbwBg6V+5IjndkhUdM5LqsLu/SWuMhQ= 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 Tue, Jul 30, 2024 at 01:11:31AM +1200, Barry Song wrote: > for this zRAM case, it is a new allocated large folio, only > while all conditions are met, we will allocate and map > the whole folio. you can check can_swapin_thp() and > thp_swap_suitable_orders(). YOU ARE DOING THIS WRONGLY! All of you anonymous memory people are utterly fixated on TLBs AND THIS IS WRONG. Yes, TLB performance is important, particularly with crappy ARM designs, which I know a lot of you are paid to work on. But you seem to think this is the only consideration, and you're making bad design choices as a result. It's overly complicated, and you're leaving performance on the table. Look back at the results Ryan showed in the early days of working on large anonymous folios. Half of the performance win on his system came from using larger TLBs. But the other half came from _reduced software overhead_. The LRU lock is a huge problem, and using large folios cuts the length of the LRU list, hence LRU lock hold time. Your _own_ data on how hard it is to get hold of a large folio due to fragmentation should be enough to convince you that the more large folios in the system, the better the whole system runs. We should not decline to allocate large folios just because they can't be mapped with a single TLB!