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 27DC8C2BA15 for ; Wed, 19 Jun 2024 08:59:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 46F708D0078; Wed, 19 Jun 2024 04:59:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 41EF28D004F; Wed, 19 Jun 2024 04:59:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E63F8D0078; Wed, 19 Jun 2024 04:59:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0F78B8D004F for ; Wed, 19 Jun 2024 04:59:05 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 681E8120FA9 for ; Wed, 19 Jun 2024 08:59:04 +0000 (UTC) X-FDA: 82247038608.03.660EAE7 Received: from out30-111.freemail.mail.aliyun.com (out30-111.freemail.mail.aliyun.com [115.124.30.111]) by imf20.hostedemail.com (Postfix) with ESMTP id 580F11C0005 for ; Wed, 19 Jun 2024 08:59:00 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=l1o2YWLf; spf=pass (imf20.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.111 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=1718787538; 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=cMqTDD3Eoy+/cRDy+tO1+Stw3D+Z2rha9T8EUPBjcng=; b=f3nx/bYvPsxD2XKlF01X3FqS8EnZjvfsw6x+qjQuVNyBnUQ6Gsj338U90H9bw0Ur2T1Cko ag8n7NhuuqOC8Y8macYfW+L0uTyPy5ubmoqWwSNcK3bYlKg+5XPK6XZQCN9RA5jA21M45S EYABW4ts28JcnzHUwpLrwmH2SJsLAxg= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=l1o2YWLf; spf=pass (imf20.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.111 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718787538; a=rsa-sha256; cv=none; b=yivGSKfnVT0XpkNkEu8BRg5XAVUUiOUnhYh83ekwEnzvsaVU/dMQ1hyF5OiOcWCvOQRWMk F3yD5BxGO1LH3fA2h24NAC73bBZQbzLPB1xU9Xe95PIN79ecL58bpK/ZGoJi5BJZ09uT7O eubgZ0kurxndag+SvKnejvg57GvnMoM= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1718787538; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=cMqTDD3Eoy+/cRDy+tO1+Stw3D+Z2rha9T8EUPBjcng=; b=l1o2YWLfN4Otpp/KQuD/igmy8nYxgfP6nSMAhFfjruEWN3Y0JrqXoESeekAJ0w/KxC+cqhZtbxalnxvU4kHv2/tkYIpGU7uNP7/wSc1ecpQ7kHaFecxFIR66bwuAaaBpcWojBpY3PsXIG/1rgjrRORI8KJjQseiOdzGXRiMEeUc= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R461e4;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=16;SR=0;TI=SMTPD_---0W8nfcRp_1718787535; Received: from 30.97.56.56(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0W8nfcRp_1718787535) by smtp.aliyun-inc.com; Wed, 19 Jun 2024 16:58:56 +0800 Message-ID: <6f133631-7895-46ae-b933-68627f53c866@linux.alibaba.com> Date: Wed, 19 Jun 2024 16:58:55 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/9] support large folio swap-out and swap-in for shmem To: Hugh Dickins , Andrew Morton Cc: willy@infradead.org, david@redhat.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 References: <20240618130538.ffab3ce1b4e66e3ba095d8cf@linux-foundation.org> <475f0f2c-afc7-4225-809f-93c93f45c830@linux.alibaba.com> <2683b71d-aebd-5527-348c-18c0e021b653@google.com> From: Baolin Wang In-Reply-To: <2683b71d-aebd-5527-348c-18c0e021b653@google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 580F11C0005 X-Stat-Signature: eua3dgnby6naryc1mck89ggsyoqb8e6s X-Rspam-User: X-HE-Tag: 1718787540-250354 X-HE-Meta: U2FsdGVkX19IqMhzF4xHSjlXYHNwFCZJYMLv4p84//hxsDdtCXi0U5hd3zpgisfyKg8w6OXwJEd0jMrhHqEmXSvPe7sqFNr54EBfROsjMfvjG1p8bixAYMNbnF+A2BSayjXASyH06k5R1tPC6wF9UTAFHgwMcFc0KVSagBHzAatjcdtgzHZLSx60LSOdI1UJzyUwMGiKh05i+1SI4XaZfHh00cjUfKOnTDfLg2dNUCfoQWWnsVaweR2mJNf/zXfZD24a2BRjnBiTpwyb2HvfwJxpw5f5DKtr1wQimEPkSf5R5qwgIF7nWqac3PbzAZ4qUhxrv9VkZ8IzQ+/jioDgHAhpHgpovCYKk57PFf64BggePaJLlAm0WIlEuDkJE28W6o3dwXZX/D2vFUtII2dGGsytINp3TovUlKtmjHZCZ2U6q3jSUvHYk/FUyypg5gQvz4RI66BIlFcHACxCoZza3M2DqKyFLrV2V0bI5UZ7xahWioi4aQjfVkiYoJNRadchluhOFoowjZi0lc9G9pbF0wmdoeHXqHBgJdwAUN3sLB50S9FYQgZ0pWL69HJ3q9RLEVEID6orrNB1kQcuvJKcxfQm/AKiwTyRGt3/OVKjWI074/McVvEMzMrtRTJ/9bxv2MA0poKV5fZaUROYA+K+L+fRt/HUZgqRn0nVYYkdo1pzv5UsUNJUh+WuKE1Ow9nDIQ8IW7cQSZT+G7ZFoVpq8N5EKB5EhyNNsrfztPxNKHtfRjW/sVGsL0lLIdMxm3vpeOE/V4uhUDeYRbekNoeBEMi9eP5UYzHwv91iC503TqZmsy3sz+JJziAnDnFhA8aMTaXCzhTs//QSnbRwJzyimJB1iuyFTv9Z9tikSEbuotaT88HZGLcnb/uWTswxVwWyF7zsOxYTmYPTJFyF4ONog94u49f0xvWKrkCtUN1mQr0AsxUP7dzIK/WTSI1HmV2y6+uAhYawJKPCGeDnwBs MoAYc0za nuYJcMSgRQXrI21PMeOU6jn+WFMifXqAut2dw9VLqsoUA1ixedt5Lb3BW/MtBZXAlVm5QC+bnSCJbG2Mw7ymJZet+20aqeQkXJLdT6Br1zV5zYLUKhhXDG4b+2VAVE7gPYOOptUz2Ej201Z1lVbNA/b6RrvovCDSmBPj2Rqizaff9qhRZFrOS76U8WAAlPPIvXmyBs0Rs4JmWM/Ik/xL69z5YcPSDyRLHN+YNf6I6AKny4CRb3ECsi6mrkNmCvFZkiThV6Ul3U+Gm4iJjcSQILMh4v6nHR4kStZgZ9XH7kZ+rYVgMPZUDmuUblhfBmJzX7yHl 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/6/19 16:16, Hugh Dickins wrote: > On Wed, 19 Jun 2024, Baolin Wang wrote: >> On 2024/6/19 04:05, Andrew Morton wrote: >>> On Tue, 18 Jun 2024 14:54:12 +0800 Baolin Wang >>> wrote: >>> >>>> Shmem will support large folio allocation [1] [2] to get a better >>>> performance, >>>> however, the memory reclaim still splits the precious large folios when >>>> trying >>>> to swap-out shmem, which may lead to the memory fragmentation issue and can >>>> not >>>> take advantage of the large folio for shmeme. >>>> >>>> Moreover, the swap code already supports for swapping out large folio >>>> without >>>> split, and large folio swap-in[3] series is queued into mm-unstable branch. >>>> Hence this patch set also supports the large folio swap-out and swap-in for >>>> shmem. >>> >>> I'll add this to mm-unstable for some exposure, but I wonder how much >>> testing it will have recieved by the time the next merge window opens? >> >> Thanks Andrew. I am fine with this series going to 6.12 if you are concerned >> about insufficient testing (and let's also wait for Hugh's comments). Since we >> (Daniel and I) have some follow-up patches that will rely on this swap series, >> hope this series can be tested as extensively as possible to ensure its >> stability in the mm branch. > > Thanks for giving it the exposure, Andrew, but please drop it from > mm-unstable until the next cycle. I'd been about to write to say I > wouldn't be trying it until next cycle, when your mm-commits came in: > so I thought I ought at least to give mm-everything-2024-06-18 a try. > > Baolin may have fixed stuff, but he (or the interaction with other mm > work) has broken stuff too: I couldn't get as far with it as with the > previous version. Just "cp -a" of a kernel source tree into a tmpfs > huge=always size= failed with lots of ENOSPCs, and when > "rm -rf"ed lots of WARN_ON(inode->i_blocks) from shmem_evict_inode(); > and on second attempt, then a VM_BUG_ON_FOLIO(!folio_contains) from > find_lock_entries(). Thanks Hugh for giving it a try. I also can reproduce the WARN_ON(inode->i_blocks) issue with today's mm-unstable branch (sadly, this issue didn't occur in the older mm-unstable branch), and now I have a fix in my local tree. But I will not send out a V3 so quickly, and I agree we can drop this series from mm-unstable branch until next cycle. > Or maybe that VM_BUG_ON_FOLIO() was unrelated, but a symptom of the bug I did not encounter the VM_BUG_ON_FOLIO() issue, but let me try your testing case... > I'm trying to chase even when this series is reverted: some kind of page > double usage, manifesting as miscellaneous "Bad page"s and VM_BUG_ONs, > mostly from page reclaim or from exit_mmap(). I'm still getting a feel > for it, maybe it occurs soon enough for a reliable bisection, maybe not. > > (While writing, a run with mm-unstable cut off at 2a9964cc5d27, > drop KSM_KMEM_CACHE(), instead of reverting just Baolin's latest, > has not yet hit any problem: too early to tell but promising.) > > And before 2024-06-18, I was working on mm-everything-2024-06-15 minus > Chris Li's mTHP swap series: which worked fairly well, until it locked > up with __try_to_reclaim_swap()'s filemap_get_folio() spinning around > on a page with 0 refcount, while a page table lock is held which one > by one the other CPUs come to want for reclaim. On two machines. > > None of these problems seen on Stephen's last next-2024-06-13. > I had wanted to see if mm-everything-2024-06-18 fixed that lockup, > but with the new problems I cannot tell (or it could all be the same > problem: but if so, odd that it manifests consistently differently). > > There are way too many mTHP shmem and swap patch series floating > around at the moment, in mm and in fs, for me to cope with: > everyone, please slow down and test more. Sure. I will continue to do more testing. Thanks.