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 19717C6FD1D for ; Tue, 14 Mar 2023 09:48:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 83E946B0072; Tue, 14 Mar 2023 05:48:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7EE956B0074; Tue, 14 Mar 2023 05:48:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B6CE8E0001; Tue, 14 Mar 2023 05:48:33 -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 5D29F6B0072 for ; Tue, 14 Mar 2023 05:48:33 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5E59D1C6250 for ; Tue, 14 Mar 2023 09:48:32 +0000 (UTC) X-FDA: 80567028864.13.2A99BC3 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf19.hostedemail.com (Postfix) with ESMTP id 1F94F1A000E for ; Tue, 14 Mar 2023 09:48:28 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=NsCW7HM0; spf=none (imf19.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=1678787309; 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=KvkrJuNpmS0Z7W1CWfhYtH/ZHY1i+0RPugx+yAOHKow=; b=H1pN+XPgPLLrZJIwJTMQ0Eq+ms3jKdKNZc3BzgvCkTiADvT5NAv5srAuQJlkQybquoRPyt M2IYOVVBJEJH+qYF3DzzSYX54Ayqq3j6xjz6ufyjF6R0Rxe+IXtQF2/oWCz2epWpCmihjO s0hX2RgoMwCMRDPKToimmplKjqJ25Qs= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=NsCW7HM0; spf=none (imf19.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=1678787309; a=rsa-sha256; cv=none; b=V2Prv8UomdD0HyqTlzlzcFeq8v9BORNSlanBD9gb7Zd8BX55cBZuGRelvpUE14zaGUvlK4 qfVQaMFffhcQTP1JqvhknT7m8xfQ/q1OkktX4XAFyBMEmocXDy6YrMYBboCoXY2fAbBHi+ dy3SgQklctQz+Xz16lUz+NoSn1XqXDI= 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=KvkrJuNpmS0Z7W1CWfhYtH/ZHY1i+0RPugx+yAOHKow=; b=NsCW7HM0axswDwCsonHqBEvFbV sFUP0IhXymLrGfmtOq7edxnWgA650LuiZlCbepA1vOR/t4YOSATdyOCUAG75kRGm8oTqzSorgmiIp fnxooJ+1UHzQWD5RQjVtQRJNjWVcJ3k5ynbyPuB2eLI7+ApJLSDyJ2mUkzz3WPUV2mjXRk6a4wiWZ 2+2inhGFLVMRGxVYKEAeY1USzdA9FP7kZ4q/XBe/U+o6O7sCkHDxJWzUzxqL6dXlILxubnm6B2J4+ MBtvw1IisxNDqE3zirLA9GDSmp55ohJVs+tzcU38K3X7653QLs7nryiTf1LJSI256SRx1jm3LMNuq VlB88PTQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pc1GV-00Cmjm-E2; Tue, 14 Mar 2023 09:48:19 +0000 Date: Tue, 14 Mar 2023 09:48:19 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: Yin Fengwei , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5b38c161-7615-30f0-f3b8-6b770e2a74ed@redhat.com> X-Rspamd-Queue-Id: 1F94F1A000E X-Stat-Signature: yjan74nqb4odfgzxymn7xebieu43znjd X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1678787308-908637 X-HE-Meta: U2FsdGVkX1/Hz7BgPh9NkmiVmF6bNu0ZkU42dQGfwhREE/lJBZhDtC/FHkdZRdzK3nG9jnwhkhH0Q51ufQRzcbZPA/AwMO6QkEkdegPnLasibWKNQFR+lzUhvXgLEPC5aaRpuruGAndWgYBCyZq0rZawEAe+J8G7zErbHPYliZz27x/Q1kK+XklWU/c18dYQK5G01n923bIxs2a5Azr4/pw+YmWclS2C0h2Cyh2gYg901V9JUA3q/+txXgn0AQOj9doj1Zx/bFP6gv3szv1iOnrZ3TS9qfLmL8oedseC3rNVPPkocQ/E9E7O2+PXcRACceTM9RedzC1EUi2pBDcFRZks6aWZidTGpUn0ceM9K8RHuj7ZsOigIswvNFTomjTRpPIz5NFEMN1cpu6veKhM97/8HFj7VQc8ywPVTUnP7Q6A67o2wnq1DTDvS87aoHk9nHUisuXYMfKn1Us3fmhUFLj/hG7jXQrQeOz7TYS3PIPVWu0u2yty8hKu1GUgbZnnWiTb2jAENr03HfWOXoK2aTQ41Rka5hB+990C/ZcBtExom3Z4ia5tvDFiututAfj4nyJllq5E+HAop5wrCO4bIXJofIu3CuILdlDL0om+pSd5jEotGgE1JCXipFqEjo2/bPIfInpiFvn0K2YqlmsngnBw8DzHRgoBK/IcO0vY5gtR4HhQmsHne0GCAAxPF+0imtQnV735ioj3uxD/kVLmf6JAhazBNbpiB9MZAq8J09C0BeVmDcVch2kb2mcnOmzQBX7S/o41N/bxsIvXvw2LC/PC4kWQa37/4OHnc5VJOkaRRyeLJ+pucvViGfToZopjHHi538Ii7GSuuCeBwdGsaRMAtr9FfViG859jcB2Uh3WVkga/filJqkgTg/MStrYd8SrqNtBPd9pu4wqhhk/p9KsCYg2jxWi8p+e08tqgrq9RS+e7qunl92DZpScDC7vyN6OCBzmkmCFkOS9j7h4 1D81ZOxq MtZSM5ZnnVD48axWa22NQ3UEIkZl10MJe4n0N/gjUVh8zhuq/IOFOPXrbJiTB5/hYt5M3JjEoAg1o0hKdNwqhR7YKHzx/+zIxfa8d/9oXyLjETtSN4J0fh8cLitMDAnlTLmYGmLzxSUV7al/UM4Eh3psp5aXXUHKP+kXn4EITuqOLVJPAaDz5Gf/K9z71c0vkcMCJdTW8FRMYxbQ= 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:16:09AM +0100, David Hildenbrand wrote: > On 14.03.23 04:09, Yin Fengwei wrote: > > For long term with wider adoption of large folio in kernel (like large > > folio for anonymous page), MADV_PAGEOUT needs be updated to handle > > large folio as whole to avoid splitting it always. > > 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. Even if your madvise() call says to pageout all pages covered by a folio, the current code will split it. That's what needs to be fixed. 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. I'm less convinced that argument holds for page cache pages.