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 B55C1C2BD09 for ; Tue, 9 Jul 2024 22:28:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E75856B0088; Tue, 9 Jul 2024 18:28:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E24E46B0089; Tue, 9 Jul 2024 18:28:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D14B36B008A; Tue, 9 Jul 2024 18:28:35 -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 AE20C6B0088 for ; Tue, 9 Jul 2024 18:28:35 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id F12D71A1605 for ; Tue, 9 Jul 2024 22:28:34 +0000 (UTC) X-FDA: 82321654548.07.0C8CEA7 Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by imf12.hostedemail.com (Postfix) with ESMTP id 2A11A4000C for ; Tue, 9 Jul 2024 22:28:32 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=1kfWTGz9; spf=pass (imf12.hostedemail.com: domain of yuzhao@google.com designates 209.85.160.175 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720564098; 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=RhsBlu6qll24zUY2yKGJJYQBS72AqtpPAo9VnNpUeh0=; b=e6tfweDHvD9Epo2tIJXO9oQOESwC+cUuaMzo0oYgYq0cISrQdfKDbMvYjbw/z3l8enHjGy wORFcTDQHWnwLp+ExNzQ9YypfulMVOVFCMB+C2MZXY0y6RrQRTgiRn7dxqZth3iGXnZVx6 IBY7WBhaecSIzDLXj20v5J4TkhGrmdE= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=1kfWTGz9; spf=pass (imf12.hostedemail.com: domain of yuzhao@google.com designates 209.85.160.175 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720564098; a=rsa-sha256; cv=none; b=ufTL93S2KQyMgb5zL/KdaEyqpXFQbaAkBIKPsE41Jyo5AFWlQ4bxLESHiUzqiImSfPeY4W ZBpnJI0SjcijLdIW+NBXzXoIKZSLu55Zht16XuV9YiLdYiskPis3gcN2G6CthRku4EEiyK Z1Sv7wPWtQeZiP6uSkfg5GyJ0Ue6AIk= Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-447f8aa87bfso135661cf.0 for ; Tue, 09 Jul 2024 15:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1720564112; x=1721168912; 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=RhsBlu6qll24zUY2yKGJJYQBS72AqtpPAo9VnNpUeh0=; b=1kfWTGz9KSQ+IkclW/nvOt8WZ8X4ts8PtUrn/n1nIRYIRb7ICaVtyK6OJuiuNPYdcE w9ShgscvhDlnqBqrAzP6k7Oma0CKvzgvqSOm+1EJMfmkArKR5+8IqLrdRB94102cZwnd N24Ack+2iG0DhOaukLFD/OVBsqiP7wOMBITh6qnScXPOYJNyUprrYAXOT70TRXOZ4V/g gqDnd8HQCeoL/ra7ZYcy3S8YQtJO/Wti7SYn0FviBE8zr9+IKEzQMjVf1eRKKt/2UfmR cNO3onWBW7AlmZnS5chxZseVUnzCSo3hEB3Gwxab52RSToJ5B1Pez/xGTHFAUUDQ51W0 HvJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720564112; x=1721168912; 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=RhsBlu6qll24zUY2yKGJJYQBS72AqtpPAo9VnNpUeh0=; b=nZ5MM1Q+0vpA2qjbSEZgY3pfAwnrjeeMfY7sfPFts93QLcUuv8SeGzH1FjjjLnxWIf WzdHp7obHEZbfPbF/eALmKKfY6NLSt9erO7fzGer6UYwKtJ5Eea8FjQo9OJCn5Z/uKUp IEfcxLoBqIFDfB7MKhoUcpVTjaZmDr5aRjU5mBgp7jM4XgfFJpcIz201l9BcRA9EhNwm /sSnLuTzjAk4BkZs+GoZXrNTNCE4RoKFpmrPlKah7V6r9pksyTqcSrze2MEhHFifr1te E5zFD/beljLUN3tcLBoRRoK2TyECUa5/FrV/jHv8/+f/6sfbMO84WHhAftjOqbqSDMNW kVXw== X-Forwarded-Encrypted: i=1; AJvYcCXBYRzleNKNfEpRyt4jkhFnWMPm1s7SSBpnU4mSx4XlR+FLheEm/nA6VUSdUiN8xBbf0MhuBcKCqC66rbhZzAln9xA= X-Gm-Message-State: AOJu0Yx1ZgtLiUVeAhSuJA5jProylTlIqhk4O0VWhmYsYNj+dRjY51zQ 6rQzwTAVEHb6O8x3J8yj0yUz9cGJLXCkhFcpWDMR0efkiTouCMB8gwgKYUIplNvRC2B1t1305YT oG37tcVF9ARBIgDrasHuXS0dU2KZN8byIhr5c X-Google-Smtp-Source: AGHT+IHeB9je+NxBzMGN6VzuBwrcm7niEoBEFnF9hemcs2GIYWQUqURUMjo2KvD1MmvJR2s2VXNPBW4xff4Hg23gm78= X-Received: by 2002:a05:622a:214:b0:444:e366:3fda with SMTP id d75a77b69052e-44b1a8fb553mr589791cf.27.1720564111990; Tue, 09 Jul 2024 15:28:31 -0700 (PDT) MIME-Version: 1.0 References: <20240708212753.3120511-1-yuzhao@google.com> <20240708151619.dc738d16d3b2d56d6c4fe285@linux-foundation.org> In-Reply-To: <20240708151619.dc738d16d3b2d56d6c4fe285@linux-foundation.org> From: Yu Zhao Date: Tue, 9 Jul 2024 16:27:54 -0600 Message-ID: Subject: Re: [PATCH mm-unstable v1] mm/truncate: batch-clear shadow entries To: Andrew Morton Cc: Bharata B Rao , "Matthew Wilcox (Oracle)" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mel Gorman , Johannes Weiner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 2A11A4000C X-Stat-Signature: i1t4wu1jm7k9izq7rt7sy1my8zosjbi8 X-HE-Tag: 1720564112-972643 X-HE-Meta: U2FsdGVkX18yBtpId4w6ONu6GbvSuixtGxz3So8XcgXvcogoqibUqZEXVnnoGXDLbP42E2rkLrV6f00esXmQM3TrkixlDk/nUQkNC8rRkXudVaYSVsyQ33e70RsZXzJUnfBUmXoodoSs+z3JbDYIbGYYB6wmxOqsb3Gd5PPUKYwPRhYw9cqaIMRRCh2tl0vLROeq8NKR+ms8GMSe6BwBJXGp8WE7CBTv+f7IQYr2mxoi8QuErN+7zgi72LyQ8JXSxB1aiZrXmPSiSngXLZHohvx0Saq6PW0VX1MPpB6zWNrV1rvZapIzgIZh0Ufag4Be3JWWI2QEA1AZCm1c6CBfNjQmvg+jfcarUyKMOrR/Fyl5F8pyweB1PWAKO9Hk7MohjzZ5L1YCYt9cY1ueBur/orS9sa48RtCluB/ZHr8+gDqKftOgnAqUnFk3uiClYk1urq0tat+A9plMGln3q/SKbEDfP0Ff+HTWBwaxn/pbZruxztNsvLVyH+m4ryQ7rR/WzBQsfSvoL9pQcR1QxeZ4+qPESaYxEco+07STVbN2SJhXK+/zZl2z0JD/vF2ZbB0tNvI+3f7ksIgC7oTU3Bvwsxgeet5eIZzNNVcgCdH+0IrPTqdZQPjap79YSjvDWHN/DxNELPDKrMUNZaWgOPvvi2V7uqlXKOqnRVDfJEPbuin+Ji91YUdUa0gLT71JDlOtMiTyTJeAXBtd+5zIRIlq4fbnctt2eNlIT8XOIoZSLlZpW3XAbs7D2iqrnEx0seszg6Wk69y4YZ607LyAFy2v0DXlfc/NOE1ETchoxxEMc3vAk2Blw5K0FIkji4E5CisRjozC4XZdmOCGT2M4wsnhguu6MVZq66OUnTNU3M6YanqWNaEahxMZ1p6zqktoWIQzfNV87fMBSkVb6QCeBgpfP0W0URUiA3mDaos/KtxZflzE2/DnEhnkmuiHvSwuz4k4uG/TI8TsLiNCazU8urK +fB7d2ZF ComI0viQtojCte8FktdwdQ+ojLJtsR7NwyQWaMon2ZursqMB36/ui1UMxKXrjOLmA/inAQa6ywaKDDsUZmCMe9nKiEJ871RPwokSYYlwc99/4bA5NhRxYqMex/qCnotBXU+c7BU/S/2jC/5tobFOgbVrEHBxTcoVQtlrMqAZLx4H4tZ7ovVh9TJiKV1jqiFufYDwPNOt667rvgyzJTFVDt70aTAJWxmWOyNn/NQXXGy1aEbihD58ljB7O3BQ3N/WfeSAI X-Bogosity: Ham, tests=bogofilter, spamicity=0.000026, 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 Mon, Jul 8, 2024 at 4:16=E2=80=AFPM Andrew Morton wrote: > > On Mon, 8 Jul 2024 15:27:53 -0600 Yu Zhao wrote: > > > Make clear_shadow_entry() clear shadow entries in `struct folio_batch` > > so that it can reduce contention on i_lock and i_pages locks, e.g., > > > > watchdog: BUG: soft lockup - CPU#29 stuck for 11s! [fio:2701649] > > clear_shadow_entry+0x3d/0x100 > > mapping_try_invalidate+0x117/0x1d0 > > invalidate_mapping_pages+0x10/0x20 > > invalidate_bdev+0x3c/0x50 > > blkdev_common_ioctl+0x5f7/0xa90 > > blkdev_ioctl+0x109/0x270 > > This will clearly reduce lock traffic a lot, but does it truly fix the > issue? Is it the case that sufficiently extreme loads will still run > into problems? I think Bharata was running extreme loads. So I'd say it's good enough for now, considering truncation doesn't happen that often. > > --- a/mm/truncate.c > > +++ b/mm/truncate.c > > @@ -39,12 +39,24 @@ static inline void __clear_shadow_entry(struct addr= ess_space *mapping, > > xas_store(&xas, NULL); > > } > > > > -static void clear_shadow_entry(struct address_space *mapping, pgoff_t = index, > > - void *entry) > > +static void clear_shadow_entry(struct address_space *mapping, > > + struct folio_batch *fbatch, pgoff_t *indic= es) > > { > > + int i; > > + > > + if (shmem_mapping(mapping) || dax_mapping(mapping)) > > + return; > > We lost the comment which was in invalidate_exceptional_entry() and > elsewhere. It wasn't a terribly good one but I do think a few words > which explain why we're testing for these things would be helpful. I'll put the original comment back. It seems to me it was stating the obvious, and I don't really know how to improve it since it's obvious ;) > I expect we should backport this. But identifying a Fixes: target > looks to be challenging. I wouldn't worry about backporting, nobody else has run into this scalability issue (not even a day-to-day performance problem).