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 ED2F1C3DA4A for ; Fri, 9 Aug 2024 03:21:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 094126B0089; Thu, 8 Aug 2024 23:21:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 046286B008A; Thu, 8 Aug 2024 23:21:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E27916B008C; Thu, 8 Aug 2024 23:21:54 -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 C3AB96B0089 for ; Thu, 8 Aug 2024 23:21:54 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 348A9A7608 for ; Fri, 9 Aug 2024 03:21:54 +0000 (UTC) X-FDA: 82431257748.20.62A32BD Received: from out30-110.freemail.mail.aliyun.com (out30-110.freemail.mail.aliyun.com [115.124.30.110]) by imf02.hostedemail.com (Postfix) with ESMTP id 5D72680020 for ; Fri, 9 Aug 2024 03:21:50 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=Jue3zfs6; spf=pass (imf02.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.110 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723173646; 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=o3+daKyS6PNz4SJpNYca26OEG08l3lxmqfUQ1bbDfA8=; b=HWsq94LO0+1Vt4ApnXcQAOI0HkfZlQFwapxTkhjCcxiYX3ElMO89tqtyTLWVehQcd9unzl 0BU7xNIrbBH1sWtrbIB1p7LZt/I81homdyoR+CuFD2sHa9MHQoGLT4JG4hHFQtkNVvqMjH Afu9MkiSkSyrcoGUkqz69YumNWNzLHw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723173646; a=rsa-sha256; cv=none; b=MS6Xyka8Un7yr/cm5mLLTZPmfNv4Al6b/YTWhxlKVnysNp/Z0xRvLj337m6rWwTmpowTNU kAZirvHAu1u/vvkNZ32ngn7h9uEhEEkkj2/3B0kyBKnnKZV1kx6bUrD2xfIl+2qx3rZutZ 6OVs4OP9UyZTw9jXLNTukkHQB9MBsNI= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=Jue3zfs6; spf=pass (imf02.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.110 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1723173707; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=o3+daKyS6PNz4SJpNYca26OEG08l3lxmqfUQ1bbDfA8=; b=Jue3zfs6ATHj6xdCJaC8IPMm+6TuZMhImiks3WzK6/fWr30vKVWvBEqiH2qLDQq2iVXOTEINarnMdY1aV6xxbvImqjelrNV3RXzBcLLcf30TbO7J0OFMNJI65uI3YXED5fAD2v4aHAICKb5y4ry/RMW1P/oGOtPjfgDEr7rhUvo= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R101e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033032014031;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=18;SR=0;TI=SMTPD_---0WCOQeJj_1723173704; Received: from 30.97.56.60(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WCOQeJj_1723173704) by smtp.aliyun-inc.com; Fri, 09 Aug 2024 11:21:45 +0800 Message-ID: <97516c66-ddb0-4bf6-a827-1b052bb5eca0@linux.alibaba.com> Date: Fri, 9 Aug 2024 11:21:44 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 01/10] mm: vmscan: add validation before spliting shmem large folio To: Matthew Wilcox Cc: David Hildenbrand , akpm@linux-foundation.org, hughd@google.com, wangkefeng.wang@huawei.com, chrisl@kernel.org, ying.huang@intel.com, 21cnbao@gmail.com, ryan.roberts@arm.com, shy828301@gmail.com, ziy@nvidia.com, ioworker0@gmail.com, da.gomez@samsung.com, p.raghav@samsung.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Christian Brauner , Luis Chamberlain References: <8a8c6dc9df0bc9f6f7f937bea446062be19611b3.1723012159.git.baolin.wang@linux.alibaba.com> <9b45a0dc-fa12-428a-8702-c7690c26aedc@redhat.com> <770190a2-3938-4ba9-9aaf-7320b34addf4@linux.alibaba.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 5D72680020 X-Stat-Signature: oiydbygi5yirrpgdoty14kk75yjayg99 X-HE-Tag: 1723173710-492647 X-HE-Meta: U2FsdGVkX19kd9Jr/rsmJKNqS4gWT+teuRsQsR0o0Oq62gOMiNeuUWGx4cAaXgJFmFmGxQxHF7EKzpybIOACCk2qZfpENe7OyYl+kZ4Hsx00qmOMHEVNjOwHh3moU1HqGBHx58OiHafEA6lrU9FiqXM755cYh3q2bqEXwX04fkX/eFhTHeBmnPbC4wZsUC4WmRyAG+DVADjCoKI05Nva2W0qLAC3gU8EGZLzE1BV46v8/P/VYc0Mv4Fdsb1GEba377+uioUxqxybbEihV+OKZ3yxDAvB5qYZrP5cC+9KmPuRROr+7+Db9HL1NQK8UVLCtL0NkdS/B/KnPZH+NvCrDYXh1XoPk1WXDA+Znog/m1Bh9/UFh8jN89f3QSIEvwzkQ0xCVY/tP+ejs/xZcAH692oLYb1JlayWnz9VsxwIwcvPe8bBNYVpHARysFxXdOAjDZiowLIvGq4DYwitGn4aNEBoKV9XSZlRRyTfpf+FrXD35uu8G5Ny+ng28BAQOAH+NV9CgYtLFtoBLnq7ayA/PDNttpHX0Vky4t5An3k99H2xrpCQw8z5n0zcMDlZR8DrAdsYNyBFOaa8d+Rqkgzq3Q7n/fqBmVFscrlce1kQ1pJ9/KUrxG78bieAwZAwtfthc4zzhTVhby1ykq+IRKxtwZNC4Lpx2dDQgMvAl9dQITN10qSWh5bVpoA5mVXwv+3q9w+gNo8sKcMrmt8pD2KERr53ZJVJrUILjNTeN6uQi2M0v06InTcAicFz7XGcZzcPAbHMcuuRLUeTlcgOEgyqaGH0GeK+zxBwnql09zZ/5aynGMxSZSP0DcSXrGl4pBW8sKXteMP5Q0MKwDeE7z2KYoS3iUtqsYZfJm9a87RzQ4A+pvhE4oSkVJPPX9REYRtKa3XtjaqhiVTFXveWbEJX/Fwi+zrrPjUa75DlA7dc8CztFWRuqzi4KwZKdKLUUSEEv1/pXZEqdewau9FF3wL 9NObMYYM BysdHuotkIPzmjzpYqb2guEd/BfOZB0BTnPu98AR8oqB0vCXLjtGnQGinh469pJjcpPBtrOgfS1+pIteW1e0Kgn7qFEBkbQbZMycnT3Ijcho/EYcdN9RS4WBhS9NXPFdeXKaeLIcwN7MA31HhCYlSAmwQ124hV6MJxJurvYHWOtDEGWxo9avzzQ2duYomo9eCYckGSHfR+o0fuaJD7LYQq2SSCX8JIR5tTRCksvqTBbfzkUuZYo74PUSl1VFx9bYwrFVV 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 2024/8/8 20:35, Matthew Wilcox wrote: > On Thu, Aug 08, 2024 at 10:36:23AM +0800, Baolin Wang wrote: >> On 2024/8/7 23:53, David Hildenbrand wrote: >>> But now I am wondering under which circumstances we end up calling >>> shmem_writepage() with a large folio. And I think the answer is the >>> comment of >>> folio_test_large(): via drivers/gpu/drm/i915/gem/i915_gem_shmem.c. >>> >>> >>> ... so if shmem_writepage() handles+checks that, could we do >>> >>> diff --git a/mm/vmscan.c b/mm/vmscan.c >>> index a332cb80e928..7dfa3d6e8ba7 100644 >>> --- a/mm/vmscan.c >>> +++ b/mm/vmscan.c >>> @@ -1257,11 +1257,6 @@ static unsigned int shrink_folio_list(struct >>> list_head *folio_list, >>>                                                 goto >>> activate_locked_split; >>>                                 } >>>                         } >>> -               } else if (folio_test_swapbacked(folio) && >>> -                          folio_test_large(folio)) { >>> -                       /* Split shmem folio */ >>> -                       if (split_folio_to_list(folio, folio_list)) >>> -                               goto keep_locked; >>>                 } >>> >>>                 /* >>> >>> instead? >> >> Seems reasonable to me. But we should pass the 'folio_list' to >> shmem_writepage() to list the subpages of the large folio. Let me try. >> Thanks. > > We should be trying to remove shmem_writepage(), not make it more > complex. We're making good progress removing instances of ->writepage; > just ceph, ecryptfs, f2fs, gfs2, hostfs, nilfs2, orangefs, vboxsf, shmem > & swap are left. gfs2 patches are out for review. I am afraid shmem is a bit special. IIUC, ->writepages() is used to write back some dirty pages from the mapping by the writeback flusher thread, but shmem cannot be written back (mapping_can_writeback() will return false). Therefore, shmem can only be reclaimed through direct reclaim or kswapd if a swap device is set up (if no swap, shmem should always be kept in memory). So currently, we should still keep shmem_writepage() to reclaim shmem pages. > As you can see from previous patches, the approach is to use > ->writepages instead of ->writepage. There should be no need to > handle a folio split list as splitting a folio leaves the folios in the > page cache and they'll naturally be found by subsequent iterations. Again, shmem is special. If shmem folio is reclaimable (when a swap device is set up), we need to allocate contiguous swap entries for large folios. However, if there is significant fragmentation of swap entries (there is already a topic to talk about this issue), we will not able to allocate contiguous swap entries for large shmem folios. Therefore, in this case, it is necessary to split the large shmem folio in order to try to allocate a singe swap entry for reclaiming shmem.