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 27348D3E2A0 for ; Mon, 28 Oct 2024 18:37:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE2D66B0098; Mon, 28 Oct 2024 14:37:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A932A6B009C; Mon, 28 Oct 2024 14:37:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9332C6B009D; Mon, 28 Oct 2024 14:37:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 71D166B0098 for ; Mon, 28 Oct 2024 14:37:10 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 250D0812D6 for ; Mon, 28 Oct 2024 18:37:10 +0000 (UTC) X-FDA: 82723867548.12.7E718C9 Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) by imf19.hostedemail.com (Postfix) with ESMTP id BEA051A0019 for ; Mon, 28 Oct 2024 18:36:38 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=T38kwzEP; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of shy828301@gmail.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730140512; a=rsa-sha256; cv=none; b=bl9Exu02TXe/wrv4gAXxF1XudCgUzyrVCHj7/GQqazbi/iUDtyaOg/pXOgzct1mOVbVql5 5deeod4GfGJyNIR/0E+j3jQUTJMuL8lnqPKJnDHmmI2qKI7l5l72qVVLweIKnlfaphShKz Wz/7ws5cQ+wMw/FuPLyGw9r/0D+e8FE= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=T38kwzEP; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of shy828301@gmail.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730140511; 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=PsNzc2OXfUCmJP2l2vN8PVR2Xt+FXaIQ1Sx8H2964UQ=; b=ks3wtI/sUnTTNlQG6d70IQ/2+YuCk4Qytz6k9yZr8gplmWWaeCvd5rBxejK4f8y/KFjjlW Ohe0yYyMZ90nZgmLH90BKaqSzvF2mxlHKzfXsw+LDVdZFWkAGmT5Y9ESWnVbQyA38seOHo frJ3gCaoAPj7GLYc5VX46xKvz/CmtI0= Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-5c941623a5aso9118116a12.0 for ; Mon, 28 Oct 2024 11:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730140621; x=1730745421; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PsNzc2OXfUCmJP2l2vN8PVR2Xt+FXaIQ1Sx8H2964UQ=; b=T38kwzEPTvl8zREogyLpsaQePNQ9UydVP2HDWh1KULaoKc3q1RXraJgbLpdP3L3h57 cMBMFu1MvmSmNAEKXxXBpfqkXjOJtpApI+1oeOaoXn//lRCjLiVX1YpAv0m8A5GW3fdV Mu8hqFId2vrMbgRSnMt3sBIrX1hd79fpIVfU+vjt+dVndH2B8IxgV6gbDhg5FDkKN5qE OhZscm8lTS81orknvahXKPnJufwphuSyTeEEppvgy8a8lwy/0oKuaTAbY6DLncyeIsO5 Up+hxqcpUF5lrDBekwzn5OQHOvb5RgKO2Yfihu6yG/V2ULvvzFlvHuohuxcTuCElZ2qy f+Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730140621; x=1730745421; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PsNzc2OXfUCmJP2l2vN8PVR2Xt+FXaIQ1Sx8H2964UQ=; b=tfJqdeEJeVmhTC/9JOeFybShj2+K8ppWHYog7TC0xE+4kyUBW/D/2IbuNY1/ifB+XA m2kcljnkvXsjh+GLm5Vu+KDCaybo9yA4bNsWkxWVNcwVzSHiQExmBGxPy+PzPkEFHgDS BJf+bUGuC4joF/fyK/8fLsU6IR7LBbCIhQOLfaCXBw8Ehsj/PkxgHDOFDSw/4yn7ZxJD rrxSc8Z44yjHPxy0CXZ7PT2MgtVETHM/uo8h8OQp3AD+8advhoqweEIwtNsv7efOi/xN ph39GMI81fehfYgjPJwnen0e4hXYSxJeBcu/9jASWcWg2EvfUdM+tbziZ7+1mtpXROA6 r6gw== X-Forwarded-Encrypted: i=1; AJvYcCWC5wrHUONKV5HIIqMqv/Uo+kD5F63qPMtQz6sVasMbSCIuqRd7DusvTyLs1b+HmCIEUuD3cXwg1A==@kvack.org X-Gm-Message-State: AOJu0Yx4q5yBlXhKxZFWHzczKSze2xM4fAfJ9YhTZ6vvzWSX/e9Ay2A7 RaP1MXA4kNTF2azWQCyUvs1D12a21gqtZ4yKDDhxhkRSe/pOGWj96I4WM8c7HS3T6LMJWHpmOUF NFFRxPBbBZVBBU5IUpJgBr147I8I= X-Google-Smtp-Source: AGHT+IG4WvxG8g6dvo3BHYFnBH+wdpUsZIaJXYJCg/ztAeenlQauWzMEMGpB8nzANJtwXgFCVFXBcS8Mgd23/gp+y9s= X-Received: by 2002:a17:907:9808:b0:a9a:ca:4436 with SMTP id a640c23a62f3a-a9e2274cc43mr41235266b.13.1730140620413; Mon, 28 Oct 2024 11:37:00 -0700 (PDT) MIME-Version: 1.0 References: <760237a3-69d6-9197-432d-0306d52c048a@google.com> <3A1E5353-D8C5-4D38-A3FF-BFC671FC25CE@nvidia.com> <966a4aff-f587-c4bb-1e10-2673734c2aa0@google.com> <5d28df34-f073-dec5-730e-a3073f14d849@google.com> In-Reply-To: <5d28df34-f073-dec5-730e-a3073f14d849@google.com> From: Yang Shi Date: Mon, 28 Oct 2024 11:36:48 -0700 Message-ID: Subject: Re: [PATCH hotfix 1/2] mm/thp: fix deferred split queue not partially_mapped To: Hugh Dickins Cc: Zi Yan , Andrew Morton , Usama Arif , Wei Yang , "Kirill A. Shutemov" , Matthew Wilcox , David Hildenbrand , Johannes Weiner , Baolin Wang , Barry Song , Kefeng Wang , Ryan Roberts , Nhat Pham , Chris Li , linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: BEA051A0019 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 37uew3gd311qynxqp6autpxa5krcwu8f X-HE-Tag: 1730140598-795012 X-HE-Meta: U2FsdGVkX18mVaa2018JkP75sk3rhuCw5hucQGpoezo2S0hjKsTNfAWv9HL+y/vFZxbRDqSubajSoeSTKAo95VufBh1Vpx+k5wBcOdqiy/Z85/PGL86z64tgf4f7pgusbINCBpOlPycl+mhZvDBP2ypBimVd4dwa2LAfd9FZdEYx4IbaXUrlKqnr/7cq516EgLzUFGI0FnznD3pEoxP9KJz7p7ddN+52iiVjp3Rcw+jAa84WIGige/IWu8+ZLskWTQZpdNDFwSO9vdPMfj53+79zdkg6qfFwoUMa6zt88vR/C7wKkY4K2x9vVrfFXV+eO1dVMaEoXDOEuYH/G08NvOzLQqi2d+AP2y9M6QQ/kxAkfmWCz2oU7y+qozjr+ExqsAumkaDqHdIc73aAa95UpkdJo8kMTS6ED4q3rKw1NjwhgLXNhcO11AmrCPFDaabcSQPtYDrSKpg0m4kvoq1uXv4wQQ7syFankN63dhp7mI2Amk9FWYPdSIBe17HHxqiQ8ZTPTNMSrpTcBrWZ6KRfdORg+asuXGHt2iuMS7YyR8fPo5fzl3gU0ksCkPeTFRAdSizDpCmsldrley9UubQMy85+2KQ9WwKpAgEqpnYiOOQ9hHcTJRbo1sCcYSfHQlhJPKzzJg4NKcr3JzxzBQyUR/EuNipQgOJzZQWxVMgcLdqQU92yc466Pt5a7zLwpryivYo8/aLaj4LGkddTsEZnGiTeOVRJjIWWNaySlSAJ2tSIDVWyjgflrwDbcfyL6KfUxfFps+lXJmy4h3z+8l/QBf1WAU3GkvFcK3cxgMFxv3yX0ol01oQ2r43ub4xfPdpwl6WMia7I/9uR3eZDitVJS8/zB8R9ZBO/EEsumJWNHvuE19imJjgcdxNpuG66wSdlcimdXwhJgvBjK2UjLM0paymtyxDAnr4H+r/fiLmZ7vDAEKAbISFIiiBcC/37acdjzt3LLZDaW4aC2bCK+PK IdFMgSrI eL6OmQ+bDhqEFkXDA4CcvW6A/1NIE8MAQbzFwp7DXGcXx/eVJikehwVmI6QcysFjtPU7iyGpoQrRMedRofdQj/mbbN4ahWv9e4jnua2NRcVa3NGaXe7SU3xtjfe+Q8h/Py+ASE34w8ni1XkowsTG4vypUcIPYKH1AgoPdLhoCnsFWCUbs7u2j6gtotD6yXMtbS2wWmlWaHtrwVGBCio4Y1pEtOw+Z+4YvZudkMhRJ9l5e2hSnPWPW/nDxpyY8T9vjlwZX+73klVTTmT1psthJIB4ZUsrOG7Qg9QoBSfUqKl5+QTRlIaK3ccBGJJQ/+pPdOKh3EYBZLaTxF0Y/xG4D+PtNyNLN1kLCCmyNIzZVp1iKmlfNpBI/QcxdAt099ESbKZNN8owN9rTGEW5ht3tm9YyGfUfC+3R1rA6UOUJU35DrpCMMoN3hccflaSZ8apl1Cw7aQkkPB9Z/zpY= 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 Sat, Oct 26, 2024 at 10:08=E2=80=AFPM Hugh Dickins wr= ote: > > On Fri, 25 Oct 2024, Yang Shi wrote: > > > > The other subtle thing is folio->_deferred_list is reused when the > > folio is moved to the local on-stack list. And some > > Yes. > > > list_empty(deferred_list) checks return true even though the folio is > > actually on the local on-stack list. Some code may depend on or > > The code definitely depends on that behaviour: that's how folios get > unqueued when refcount reaches 0, whether they are on the public list > or on the local list at that time. Yeah, folio may have 0 refcount on the local list after that folio_put() before it is moved back to deferred list. The main purpose for using folio_batch is to disambiguate list_empty() so that we don't rely on this subtle behavior. But I soon realized this may make deferred list lock contention worse when moving the folios back to deferred list. Currently we just need to do list splice, but we have to add every single folio back to deferred list one by one with folio_batch. It depends on how often folio split fails. > > > inadvertently depend on this behavior. Using folio_batch may break > > some assumptions, but depending on this subtle behavior is definitely > > not reliable IMHO.