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 D6583C83F2C for ; Tue, 5 Sep 2023 14:01:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E9BC06B0074; Tue, 5 Sep 2023 10:01:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E4B216B0075; Tue, 5 Sep 2023 10:01:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D3A848D0001; Tue, 5 Sep 2023 10:01:35 -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 C4C036B0074 for ; Tue, 5 Sep 2023 10:01:35 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 71B32160869 for ; Tue, 5 Sep 2023 14:01:35 +0000 (UTC) X-FDA: 81202706550.08.1F7D637 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf13.hostedemail.com (Postfix) with ESMTP id 1B4CA20034 for ; Tue, 5 Sep 2023 14:00:55 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=HiVjNnq8; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693922457; 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=ibfxdGmSo86+K1UgPWvO+NuK0OOsreNypuqWE+79gAQ=; b=cwOLQ423IlfVwiRp4O+lOI06cyNBt8n/YjdNwaVY99OHi69D1ra7tBV3MZS/kQC0Ehxcw+ asuWAUWUtl6xDiixoHFbbXqweSczfwwkPASfsl66TQnQEvlfut2BsIEJljVmSBuN9uCVhb HnQdPJyykdgFlKShg7f2pqndzFsqnU0= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=HiVjNnq8; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693922457; a=rsa-sha256; cv=none; b=IIXmYaz4bVH6i2Gn8OUyJBtuVvrzJ9yQM7XxIwREH6pgk1xI90umb85Vqh6XSSbXeTGvDU 6mcRX8X1CGudf3D2rJP9a9koJyF+vXtv/y11Zhl3zYoqsqwSw/AYIXqp5TZjPVXAKJSA2f n1TuYkD/M8emAYWwMJuF4hdpRLpfsjk= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=ibfxdGmSo86+K1UgPWvO+NuK0OOsreNypuqWE+79gAQ=; b=HiVjNnq88ZmvKfUjlKysb1X83D 5O7ZBuG9DPkBeqvA7CO1p/Sl+BgtfrpOZQiV3KYhMbBLMlPkASn6aTYQvR1DbNX4Zox/+vK6m9OU8 zJS3iv9KIVoItYkk9e1ZyDjnWRHdlBOgKYflmaEfnhN02dzBxTg5sCXhrAGqDhYEJpEpSiKMUe5Xb cLRy/tlaV7dINOu4h0ks+A+IG3TTskMgrw1DhxKH9T4UW9ZavCE9GGVJxMrO364unzbcRpTQUVnBG WXXEvDiuJyHboHY2WMTxtWSGq3GcCVmXchn5QSsCJ8TKAxOPzckFCeXku3paN1HQMsxEt1UA+bojy P9XiSukw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qdWbr-00AH4W-KE; Tue, 05 Sep 2023 14:00:51 +0000 Date: Tue, 5 Sep 2023 15:00:51 +0100 From: Matthew Wilcox To: Ryan Roberts Cc: linux-mm@kvack.org Subject: Re: [RFC PATCH 00/14] Rearrange batched folio freeing Message-ID: References: <20230825135918.4164671-1-willy@infradead.org> <618edcc2-c73e-4902-95ff-947f2d63838e@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <618edcc2-c73e-4902-95ff-947f2d63838e@arm.com> X-Rspamd-Queue-Id: 1B4CA20034 X-Rspam-User: X-Stat-Signature: q96qspz5kmizi9yobso7ocqjzrkc8j1g X-Rspamd-Server: rspam01 X-HE-Tag: 1693922455-209542 X-HE-Meta: U2FsdGVkX1/vxD6ERmtHteaASCvnLxfuWic8YH8p/6aoYI8RNJLm9kRlZSRF6MwVWl+CSxCWF6rGrmyz/VxVYxxXnAlbxewbanCpAzOMSA2HGvKI4BL524NdzERxLrUqd1MYzFoigqPEkuC05U0pckfDqmgRey3VE8GK8MyGRGbIs8ZYX/2alPtP0pEVgjeAMN844K817n25Cfa9LXX6R07m4/eHJR9N1Sy1zPx7mtAWPq/6Rfb0xBbj/Z1TYaFuZ9m3sTLCAGTzoTwz2MbLi6syms1dAUZWEjxYucD1d9ouonUtSSo9qx58pxtuJdpd8mjys0R0kK4LwSxtKZXkjhGJBe7tcf2eQ8QYPrbKA483l1pYp2jlQ9kWUgWoif4WEO7O/WAxQZo+sNfX153lveo9sRakiF04qRpxembrmJjNiZqECLlGfHZgq3SyHWzo3+PIHJqpO3nzOUrfnamCECDJZ1uqlQebh1M+qV8KWIfR8/D9oZxUqp0uKtHGra6gD8oMlJamT3YjnPq7FKSzvV4IrFIhf1unlg8wlfuTOi7QmVSlkU9dAUKtGurBagfiHxkvg6mEQeMXlxusx7CBF0jF85eWAQftlyHibpY/aNDIdddE/On5DOv0/BZDG/2ECPJ9stEqmuyJJWQsAADt8cPJqzrRqtG8P7225mVIIdDCTOJqDWyZe5p8yDyUrxoOvWI6lbim36TNVsScq95b05YDxeKlGQG0fesYZIO3QXYgJlyztHNtHyj9vS20oHSuJkyre2dUwWDxl91vimAqu8+SB75XS+lu/VcBWI4AQ2t1pkrP92YeaLzFbIKYcrGgQH9WPsFp50xRh/3TfZxv9RY0lzqaao8Uy3wL5/2I/PKxgtXdtABT4lx07pu75oASwigRgLnYUBoanksFzEUeEolkYZX/a5Al13r3HJRme1HRyWoZRtXASUW7yrLJ5mT5/2f2OD0EWGrCbE3RfOb n4fcF1qx IHztrGcryN7DaVSOdQ5oLSB1ILYdGYWWyUjAloUR82ilhT0PH/4C1l5x/GCuNCYabWSlW1TPP8f6dNcm1M+vkRTV3iYIc0HOO8gmS+24mvRd4SwA8MSJHB4IskssIAEkS9rvQ0VgnROCm3Jc= 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: On Tue, Sep 05, 2023 at 02:26:54PM +0100, Ryan Roberts wrote: > On 05/09/2023 14:15, Matthew Wilcox wrote: > > On Mon, Sep 04, 2023 at 02:25:41PM +0100, Ryan Roberts wrote: > >> I've been doing some benchmarking of this series, as promised, but have hit an oops. It doesn't appear to be easily reproducible, and I'm struggling to figure out the root cause, so thought I would share in case you have any ideas? > > > > I didn't hit that with my testing. Admittedly I was using xfs rather > > than ext4, but ... > > I've only seen it once. > > I have a bit of a hybrid setup - my rootfs is xfs (and using large folios), but > the linux tree (which is being built during the benchmark) is on an ext4 > partition. Large anon folios is enabled in this config, so there will be plenty > of large folios in the system. > > I'm not sure if the fact that this fired from the ext4 path is too relevant - > the page with the dodgy index is already on the PCP list so may or may not be large. Indeed. I have a suspicion that this may be more common, but if pages are commonly freed to and allocated from the PCP list without ever being transferred to the free list, we'll never see it. Perhaps adding a check when pages are added to the PCP list that page->index is less than 8 would catch the miscreant relatively quickly? > > My best guess is that page->index still contains the file index from > > when this page was in the page cache instead of being overwritten with > > the migratetype. > > Yeah that was my guess too. But I couldn't see how that was possible. So started > thinking it could be some separate corruption somehow... It could be, but a value around 10,000 would put the page at being offset 40MB into the file, which is entirely plausible. But yes, it could have been some entirely separate path that freed it. VM_BUG_ON_PAGE() would dump the entire struct page which will give us a lot more clues including the order of the page.