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 39DAEC2BBCA for ; Tue, 25 Jun 2024 04:54:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A71AB6B00AB; Tue, 25 Jun 2024 00:54:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A20976B0116; Tue, 25 Jun 2024 00:54:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 910C96B00E9; Tue, 25 Jun 2024 00:54:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 727946B0333 for ; Tue, 25 Jun 2024 00:54:55 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 266E31A1657 for ; Tue, 25 Jun 2024 04:54:55 +0000 (UTC) X-FDA: 82268196150.26.A867D25 Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com [209.85.128.176]) by imf22.hostedemail.com (Postfix) with ESMTP id 507F0C0005 for ; Tue, 25 Jun 2024 04:54:53 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mGmyRxHg; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of hughd@google.com designates 209.85.128.176 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719291281; a=rsa-sha256; cv=none; b=gCesdqrFL/xrEnDZMbEv8nFJ55iqWEGAVQwheve+wE+EkSrh4lEOYtBPK0Y+E71+rJJVME rWsVaM2piDGKCZAdk4q1m+IS6EaCuI6rs/B3ynKw33NbsbuBp7Lm5zuK7k9Lc4+UX/dKkH x/8S9O3/0XfJ0wQU/eKlHt/YjCqeATc= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mGmyRxHg; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of hughd@google.com designates 209.85.128.176 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719291281; 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=jtwAbstTTXWhbiqTYTn63sZCI1kd2+HDy1+CHZY+TrA=; b=34wtCH0CmRmNb83Ffeq/nePJ2jd784l+j/tBBxDBcpCAe0KP0FR7f5/YpWuYWHxf+sWJxE BeuqlNDHvCieZPFALEQnr49EwXk03DPAjIMZojcGp46LaodAGRbHt8vDe5tfQFmxBNMV45 ziEAupbPioAO3iSFKq5MeadkruE8Px0= Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-646645f1387so8269727b3.1 for ; Mon, 24 Jun 2024 21:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1719291292; x=1719896092; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=jtwAbstTTXWhbiqTYTn63sZCI1kd2+HDy1+CHZY+TrA=; b=mGmyRxHgydeGC0QMZCbsSj3lfYShAIqCPCfJujmJeMBiU6cosNmVL0+sUi9GxQtzg/ eqeuyfwlvJlmksVSBiikWv0usyHCucoxl1eLw+e6X4bMahMY2YcDdnYM7p2cBAlWbYcm iEH4prohIeF0FibDMdQcKimkJ0XREf3aoTUEGb4UEB38qF/4MPQ5LcJg+3dWfk8yOEv/ N0NEbK+zWQdV7InqlUC6p5LgHYo3Cgigy3hnoKV8SI/MmuQ1TADaQ+ekVYhnOnCQvLdU XdroEi865qs1C1b7NFlZYdEr58f4Afn31+MkhLKPXPfU1afazjKqSo6XOnVV81vVsjna sNhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719291292; x=1719896092; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jtwAbstTTXWhbiqTYTn63sZCI1kd2+HDy1+CHZY+TrA=; b=NmkmAYXFgfe6g0hB+ItH5MCHAt6f2+juG9cPNRb23PU02WnsB5rpBPtjeVeRdXkkr1 ZpKcuX5mvJal0981vPagJIueJ6KjhzPW8Gjryy7WgumynCg5YRzEYqG4IowJRMH998Yj w5rmVu9SYeXR3pmpaDKxXr2cLY/jP1KU5hPgj4doX/kCSCqbJQzHfKNvSsmXJkSPZAZ4 HFXmfn41zf3JfwhlBtr/SHWXdJzoQzvAwBbV7PKNHAmRg2TxtNdbv6SVA/MipQmKNJTP l4rZWV7rjQlnyFIwqQYEGlzjmw3H0VPqjZrV8Uc0Qp+cze3uxe2F9WC51WuVeTxdg2Gt qj/A== X-Forwarded-Encrypted: i=1; AJvYcCWH6F4IiYwyL6etTNDuBNhqA3wKQsmzqurs4ykjTWpRsWru+nn6FhuY7EUwlbL61uCOge0wtLtnPOAuWMb/C+RXGI4= X-Gm-Message-State: AOJu0Yy29U3KCyMbX/zNq6P8g/O1+YG6n+JbddmkewnQ+NJFZupoOG3L p5/tpeT8AQzBLhtTjAWebqFZ4mY85jOgcIBRwCF2ULDedc1VcTZVd3M7eanOHg== X-Google-Smtp-Source: AGHT+IFWDp3NNaxpCABF0X4STIcfJgY41MVmcNp7/xPmE5jFZbXgAsfp/9PE+kWj8w1emUGzMeo3NQ== X-Received: by 2002:a05:690c:4b02:b0:61a:cd65:3010 with SMTP id 00721157ae682-643aa5a259bmr71230307b3.30.1719291292081; Mon, 24 Jun 2024 21:54:52 -0700 (PDT) Received: from darker.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id 00721157ae682-63f14a3caa9sm33515867b3.86.2024.06.24.21.54.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Jun 2024 21:54:51 -0700 (PDT) Date: Mon, 24 Jun 2024 21:54:40 -0700 (PDT) From: Hugh Dickins To: Andrew Morton cc: Hugh Dickins , Barry Song , Baolin Wang , 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 Subject: Re: [PATCH v2 0/9] support large folio swap-out and swap-in for shmem In-Reply-To: <25ae21b4-23d5-73ba-2e0a-e642ec4b69a0@google.com> Message-ID: References: <20240618130538.ffab3ce1b4e66e3ba095d8cf@linux-foundation.org> <475f0f2c-afc7-4225-809f-93c93f45c830@linux.alibaba.com> <2683b71d-aebd-5527-348c-18c0e021b653@google.com> <25ae21b4-23d5-73ba-2e0a-e642ec4b69a0@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 507F0C0005 X-Stat-Signature: 7rmywjjiz5e5n6cnam1ip6cbr1qxhigx X-Rspam-User: X-HE-Tag: 1719291293-111395 X-HE-Meta: U2FsdGVkX1+W6AFGlEPNmIphscgagUxb7hK1FuX9Mip79cDftNkfhpHfHOXw9xX5Ium64TKK+Z7E2JvXm+wlCTtT0NJBjX/dE319pUsGxbcWnUR23HZUDixhIigvQnMau6xqBW40sNROV7CoLfpawFVnu/hLVRsdWPlgndo3PtNq09lFET6rbsvCuEMQEOQpa9IgZYpoHiANI5d4VT8bbuVJr9xn3FikGWROxmBpBEn1/gxNMl2/gBlCxlGfeuoqftgSW/hFF+WuJ8W8QCkjyGhk2uYPF5ikusrJh1G+oWTTSQTFGWqx6uoJ8LXLYaSrtLj4I08oTHnXuQpiARQipIfVw8KE0D+LDAog7imD2DeN1WQGT3eowKmat6+R/rlIvhlEmeDCYaP0ZdbOWfqaYj4ZtZvHMKPR8/XS4HL2itxwpdASSNiS0l2wArVoUtTIPY87g6O1zoXXLC5NccM3tRXPLesEI7030a/LJqkLVFQeML7CGnfAZLN5EQfIfvXHX5GbdjLYMWQ0ThNsOr5T3CIRR4V+Ye7gOK8EzUBvtPsuAJNP5KYGsvDmgsEBLnojfiYlD0re63onDT815+FEZjVcPRDiISjx7rwVJhTVEVpDXxHkbvX1Ym2zFaQey0Qrvj7LlmSuIsiDag9huH2uKZHFUWz4w1FiuZ78hppBjzHeeNgXR+pn4W89kiZgWoU9UfnCY3bU0wdL2MWD5YKSSo56a4N/sw8yuvywfWEyrHSKalxWsq2UFDRcXaZ0NmXuCOdp76uGnuuhUMfJTD/f3vKF3u9M3OMZNxRn2jCeifm43gzfCrcD3INVP77VZsmChoMWp0x6H3cM2bm/p507wbEoHR/xuxEuQNAnL8YZ9HZ71uSyysE6Gzmb39OX/GC6g6oU8k5sWMFzCobRWzZF40o1eliVuIIoDGVt6eatmmPcm1OCB2gwpNi0ACRIncJMhVkiwCyBQ2K9S0wv58D Qglgkhte l/hjdc3jhMJ/n0IiZDJwG0xcGBBdyLkA+cc2UgO1RBuimXfCWBaIKRJ2YCWT3kX7+qH0w8EjSYudTdx5eSjgWQCi3Kor+QhVPSrBjzAMHtehP83o2nKBILqnDfRABBVVBEbcH/GdBma3E2H685KKfHLp7SHgJ7pPCrWXqsh/WhnwbYulJRrLuUmImaSsrxSDtZyYHCYfFXU2LXy9vY8NRPEtTMJ4BVT4l1LRVgeG9A7BpURJCjuTEhOXKaEMVx4CkIw2n5GO4kqLWtwXhUkxR7OVPh3mWny2KhkVeljHHfwV7iaEKZd94LNqd8P+7lAs4K94Vb+F7HyujiQp6XZP4Q+omBg== 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 Wed, 19 Jun 2024, Hugh Dickins wrote: > On Wed, 19 Jun 2024, Hugh Dickins wrote: > > > > and on second attempt, then a VM_BUG_ON_FOLIO(!folio_contains) from > > find_lock_entries(). > > > > Or maybe that VM_BUG_ON_FOLIO() was unrelated, but a symptom of the bug > > I'm trying to chase even when this series is reverted: > > Yes, I doubt now that the VM_BUG_ON_FOLIO(!folio_contains) was related > to Baolin's series: much more likely to be an instance of other problems. > > > 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.) > > Yes, that ran without trouble for many hours on two machines. I didn't > do a formal bisection, but did appear to narrow it down convincingly to > Barry's folio_add_new_anon_rmap() series: crashes soon on both machines > with Barry's in but Baolin's out, no crashes with both out. > > Yet while I was studying Barry's patches trying to explain it, one > of the machines did at last crash: it's as if Barry's has opened a > window which makes these crashes more likely, but not itself to blame. > > I'll go back to studying that crash now: two CPUs crashed about the > same time, perhaps they interacted and give a hint at root cause. > > (I do have doubts about Barry's: the "_new" in folio_add_new_anon_rmap() > was all about optimizing a known-exclusive case, so it surprises me > to see it being extended to non-exclusive; and I worry over how its > atomic_set(&page->_mapcount, 0)s can be safe when non-exclusive (but > I've never caught up with David's exclusive changes, I'm out of date). David answered on this, thanks: yes, I hadn't got around to seeing that it only got to be called this way when page anon was not already set: so agreed, no problem here with the _mapcount 0. But eventually I came to see what's wrong with folio_add_new_anon_rmap(): this Baolin thread is the wrong place to post the fix, I'll send it now in response to Barry's 2/3. With that fix, and another mentioned below, mm-unstable becomes very much more stable for me. There is still something else causing "Bad page"s and maybe double frees, something perhaps in the intersection of folio migration and deferred splitting and miniTHP; but it's too rare, happened last night when I wanted to post, but has refused to reappear since then; not holding up testing, I'll give it more thought next time it comes. > > But even if those are wrong, I'd expect them to tend towards a mapped > page becoming unreclaimable, then "Bad page map" when munmapped, > not to any of the double-free symptoms I've actually seen.) > > > > > 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. > > I've not seen that symptom at all since 2024-06-15: intriguing, > but none of us can afford the time to worry about vanished bugs. That issue reappeared when I was testing on next-20240621: I'll send the fix now in response to Kefeng's 2/5. Hugh