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 2538DC6FD1D for ; Tue, 14 Mar 2023 15:02:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A681A8E0001; Tue, 14 Mar 2023 11:02:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A18106B0074; Tue, 14 Mar 2023 11:02:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E0C58E0001; Tue, 14 Mar 2023 11:02:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7CFBB6B0072 for ; Tue, 14 Mar 2023 11:02:02 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4509880EC2 for ; Tue, 14 Mar 2023 15:02:02 +0000 (UTC) X-FDA: 80567818884.20.4A29BB7 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf06.hostedemail.com (Postfix) with ESMTP id 9067F180044 for ; Tue, 14 Mar 2023 15:01:56 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=fy8va9Fs; spf=none (imf06.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=1678806117; 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=oplNwzssvRJMzv2b7FLaRlgS85I9X8QGC+opwMhkj6Q=; b=gpBwTEQngUl9X1UmBZVlEcmC5K8NgSd1Mn2b41F4l40OlEjGiEgs2iXlZP+r/EbjXqNrxo hoCU8LWitPTiYEInvylUqlUKHmvXPTN24+Knd5AldRQ7DnNSQoGQEgi+iNoF1IzdbWnbh8 aKcK2bbox9Fwf4Jy9/qO1Jf20nrP+qs= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=fy8va9Fs; spf=none (imf06.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678806117; a=rsa-sha256; cv=none; b=GFYb/wkDsY+oZJYGM9eou4hD7o5vicyOBG0PBBLM6JAMguoYy7f5BPPabqXdHD9gJA/Of6 O95R3qOmjc84pR7ZcNxsKIOqJrdch8+wosgVS1v9QtGQepbQLBRya/jiJ4GK/oe8Y0/Iua q7KsaVe6HAYuPjGq5PCPGafhxQ9jCDA= 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=oplNwzssvRJMzv2b7FLaRlgS85I9X8QGC+opwMhkj6Q=; b=fy8va9FspRD9p7WO4h84N1hyPb Pdx7U2yYhHk/7K+wmBJtF0TvoF9TASm4CQxyRLSdZ0OXJ6ojPSa8aYgeEqNSM68kUSq6YYtNc2KJN YWlaA6wRyYvzTq5DtTVFifzXHHwOXjCLmducUY+vyN1GAGDC/D/XzEnL3LT2Y1Gc3Gw3WwM+b1HDn 5jx3isevFjc6n80EyiwxvjIMieza5zAxCqBR4mJhWZQNUgwXM7GwqSSMXT1Cp33TirixlgJn4G8kM Grs7KDizodCI+tzyZlqQevcjHltgpdntveNcpf3B+GFTkYDd+pVpK3lny1KO3Aon8qBUJTIYYef3R djaNUHPA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pc69o-00CzmZ-Le; Tue, 14 Mar 2023 15:01:44 +0000 Date: Tue, 14 Mar 2023 15:01:44 +0000 From: Matthew Wilcox To: "Yin, Fengwei" Cc: David Hildenbrand , Andrew Morton , linux-mm@kvack.org, mike.kravetz@oracle.com, sidhartha.kumar@oracle.com, naoya.horiguchi@nec.com, jane.chu@oracle.com Subject: Re: [PATCH v4 0/5] batched remove rmap in try_to_unmap_one() Message-ID: References: <20230313124526.1207490-1-fengwei.yin@intel.com> <20230313114900.96cfad6c3e4b684646f74e61@linux-foundation.org> <5b38c161-7615-30f0-f3b8-6b770e2a74ed@redhat.com> <7a26372a-a18f-6b6a-31f1-dd1c599d4f66@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7a26372a-a18f-6b6a-31f1-dd1c599d4f66@intel.com> X-Rspamd-Queue-Id: 9067F180044 X-Stat-Signature: o41a7ra8hpanqmk76fthox6e1spfe3f5 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1678806116-432117 X-HE-Meta: U2FsdGVkX1/XHkHWlQh9pgTYaDFQkekwvQDhgILAJNExL4ltuaWkysyu10IDIiwaA4ICl6VT60DWMrygoS1JZIRbmvFSOGKVjoZz/rr+VRy5um6ZukTBu/wzz0y4aZ8dFb3KTh8bFqfJu32RorRuZHTMiBa9kruU9IR/D6BKlNgl9F5lwCgCdzupUUYU/odjkin4OlsXJ4nRvQjnQ4T4rt08Tg+LhtWecW5S3Y6PNgnJw0Rt8/+aYZ94jUnyd52DDPYtDzwziGKc5KNR5ALc/bSgJvdKjh8IJ8a3dobPTgESdKl/iumFhsQ14HCQNLeT6GZzj9uc2TqcJlAG8PrpbsLdlJzgmfWKPwnwLrfXkA4lNoIV/Go5B2XQhEVxqXJ8WUvjdJPhZL+adi0TBYQ1PNdAMP/1wvCmLjcc3ilsFW3u84Oqd0HHjzwRJUj2dTNiS4qyS8yJFsDqFv0jRGZ+RNoSWeBHetlB3DsLwVSh7ATaTt/k2wOXC5nH8qnPuApeiFqW9xZwo05IcOkPm8H1Vt6oM0VF4fp2Y6hOB8nOtTcxBjX9t+l3E36J3tLevJbhfrxcjeq4FyUIBBSYoZ3MA5btDZgFUQhmJb46ynbXsknwQb4iBicU4enFKZ8Z4kmZ9uZeW5ffuMrDh054XDBso2sjqib5oCENkOphhvsQ8o0soV5oRApi1tDd2LOltStz+A9fZioQXK+hAMbZ5MYV5tU+lLzo3/8IF3da7r6lkwc0SS/t/CV5bSvE7UwQBhBg9RCAhHD/5/Rr3IXVo3Mx/EIBTXRjxqSj10UDB4lpH95vgn6flsNOPGRC2RYZ0w9d6ZHSFXrt9uY2Unh6YESlMN0KUOXcUw2LQe/LWT2CHZUdVP5Bdr46bPhbHax8ba1tTHHOlNI08m87d52pPN7Ajhg9TgqqRddv4Xfh/Bp1dtzYmFPGPQPTz8JgRe1XTGT248Y8kbv6UCO7NlH6+jg njSYPjc+ Ht/UXcePiKVDlq21N0EXoFHYyUEIFB4DOi0axIdXygDLkRtRi7wwOfAPNoHf4kfr7O7g/H/JS/l1kzGVCN9qZRDth+gjS0Gxzbx9FEoyRhRP0L4YTZ2fQnNopR92kpPXw6W6wBEWDY6eGYrSSKMHVx4c332H1hZm038+76icbupsp7aJ5IrOvtjUdXhOb7ltl3WLPQpDAS2MKBik= 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: On Tue, Mar 14, 2023 at 10:50:36PM +0800, Yin, Fengwei wrote: > On 3/14/2023 5:48 PM, Matthew Wilcox wrote: > > On Tue, Mar 14, 2023 at 10:16:09AM +0100, David Hildenbrand wrote: > >> Just curious what the last sentence implies. Large folios are supposed to be > >> a transparent optimization. So why should we pageout all surrounding > >> subpages simply because a single subpage was requested to be paged out? That > >> might harm performance of some workloads ... more than the actual split. > >> > >> So it's not immediately obvious to me why "avoid splitting" is the correct > >> answer to the problem at hand. > > > > At least for anonymous pages, using large folios is an attempt to treat > > all pages in a particular range the same way. If the user says to only > > page out some of them, that's a big clue that these pages are different > > from the other pages, and so we should split a folio where the madvise > > call does not cover every page in the folio. > > Yes. This is my understanding also. :). > > > I'm less convinced that argument holds for page cache pages. > > Can you explain more about this? My understanding is that if we need > to reclaim the large folio for page cache, it's better to reclaim the > whole folio. Pagecache is a shared resource. To determine how best to handle all the memory used to cache a file (ie the correct folio size), ideally we would take into account how all the users of a particular file are using it. If we just listen to the most recent advice from one user, we risk making a decision that's bad for potentially many other users. Of course, we don't have any framework for deciding the correct folio size used for pagecache yet. We have the initial guess based on readahead and we have various paths that will split back to individual pages. But it's something I know we'll want to do at some point.