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 B5189EB8FAF for ; Wed, 6 Sep 2023 03:48:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C665B900019; Tue, 5 Sep 2023 23:48:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C173D8E0014; Tue, 5 Sep 2023 23:48:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B05CC900019; Tue, 5 Sep 2023 23:48:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A1AFB8E0014 for ; Tue, 5 Sep 2023 23:48:17 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 5C4DB1A0BDC for ; Wed, 6 Sep 2023 03:48:17 +0000 (UTC) X-FDA: 81204789834.02.6BF345F Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf18.hostedemail.com (Postfix) with ESMTP id 295891C0018 for ; Wed, 6 Sep 2023 03:48:14 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=SDPMccRx; spf=none (imf18.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=1693972095; 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=yUxNk6mCIdMQQSCSLhp5r+AHfyihmFvRrGebxl/ACPU=; b=vlenDumS5v0SQLpHojxBg4V5uI6MFtGIwPUJ34XHJJ9OZmxDJ97gs2/dKngraMTczpZlZz DXkksa52xFOjyT2CsG5z2uO8GdfVueesFcigUpdzV/mGZ9tj6dzbYAW0LyijZrvZxAPtOr pdxgdDDKql2sU1QY8w+GBhJ5cFsFJ9w= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693972095; a=rsa-sha256; cv=none; b=rymwPnISvHzy+W7HkqY0rKAXn9frE7oc80G8+vtbvMKlc25d5wDgOSHI+JCoonVOjFyoCk VSyX8gFlywH2JQSXya0JizaNaidgBHDWpk42enUXcePVHueJubIpQgoDIxOz2LjfdMXRmJ XLvJDZTzH91GUQpMTa/8Prt93ed+zGs= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=SDPMccRx; spf=none (imf18.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none 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=yUxNk6mCIdMQQSCSLhp5r+AHfyihmFvRrGebxl/ACPU=; b=SDPMccRxf2PEpwwA83hXq2RtW8 jCpP/+zkm5RQroXMfRsCkFMoKvCqZFXMEaOui6olg3L14HKeHdKWQXWv2Eym87lB1bZO50JT72h6/ hIFR+ccxX84ICb9rYsUXNWA4Dh67MHnI9sFxCa6lyByVB6n9wt5huOSFmagRfRqUVK3jgudVTCBfT 4MNhj6c6fFElDsq7AsKYqmvqFVZO73764hY+Eapr+0xpYuSsvEsh2rFv2ieKtaMel9Hih5qTIHxLv isNfbVz0jwi/5eY5e3KHItbjI0WBhisbs5HXCs4ckP6SByPEt/ITv7duJ2AVunE19TKqOtxulgqB+ 97UhDRMA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qdjWW-00GMMO-B0; Wed, 06 Sep 2023 03:48:12 +0000 Date: Wed, 6 Sep 2023 04:48:12 +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: X-Rspamd-Queue-Id: 295891C0018 X-Rspam-User: X-Stat-Signature: pcu7qg7nen8tta1h6oefcdez6m3xf8hb X-Rspamd-Server: rspam03 X-HE-Tag: 1693972094-171035 X-HE-Meta: U2FsdGVkX1/Qj9Cpe2DAGx5aoysnaC/FqkPuT2/M+xUVcqu8opeYoiW6vh8nvZN/XPskjgbnXqzXDXXCP+niPAYde4DZ0ClmJ1RYi2dCOXJ/9O0XnG0zdXOKEsvlxFev1+aIXmglX8yYLPn4njAYVAxpt7Rxc363loxycx5kmhkSPBmF+zNCJm+kuC8ilbxW802hdANIbh2CLVyVoLnu//vCC07s9/BCFtz3W2onY1GIilGxJo8NsGV2edq2MPu23/oLvAcHI8KNqxB5rNkMjZxL8IdCiIWAsTvaNzw0OGcDbODSH4s4aA/kzB0h5qW0wQxYRdmhkAUE32iSCycPXQpVaYJImCv0VCxUXozW9vz1ua38QF+kKGKXJbdk/8vPs+JzUF1faL7182FlXfTZflMx2sdOchPsL+vRHvWbOjZly+wmoXiGQrifHJYY1IrVkn5Ffb/y1GUIZAzcwIL09PihY2HflBN1zDxRYB27eUyxwQx9zzmM4cPXOB7EaSDI+TpRmNcO4t4NkW3KLWd5eg9q32RIPwUFtgzH76eTIuchcnELr5te+rpSu3Bn6vDyTYz4qpkILkDcnXg1qG24f265B3/ISebEZpPC/zJltbcrCC3WAwGcE+4aG2dfjLm4y9ghq5bHpqNoc5l5MzDK8DWm6K71h7fc8TVJaCKPKYtFPBp2vH0PaHEjhkmvJAItdyRLSaDSe/SF5bhHaBMyx/SUC8Shn3a7wyXTmswMK4ZBLInnpbSQD4vftLpoXETogRc7nZJ7mPXRCscX+ttlr9dkNYtoZkoiHMS70fdKsYIEVTdq2IxteTbgLtnMW+3F9N84pMq65M3Py8j0wVUbsyXulWxiV8aalbIxfezO6dwmj8Zfm4Y+oEsl9KfOvrrFcvd7uU0s4fb2Io8UWMBdevQGgONWA8i8cIvl6s5n5S08feF6dm6lsXrL2PbIzenOoGCp7haMLY/5aYcGHwT 3ji7YMLJ 09GnCUplFb+YxHAijl+3Ux9iw8SD160d/VvDfpprGgX3QgeAnJNHBnBDVHk8CCS00J3IjY/xpFmmi8K9wuSYW4x68aBwtWkiDEIspIin0pS/invGLxbVBeJbN2iAY+Mn6vinCHe/EaEbtXy4= 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 03:00:51PM +0100, Matthew Wilcox wrote: > 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? Somehow my qemu setup started working again. This stuff is black magic. Anyway, I did this: +++ b/mm/page_alloc.c @@ -2405,6 +2405,7 @@ static void free_unref_page_commit(struct zone *zone, struct per_cpu_pages *pcp, __count_vm_events(PGFREE, 1 << order); pindex = order_to_pindex(migratetype, order); + VM_BUG_ON_PAGE(page->index > 7, page); list_add(&page->pcp_list, &pcp->lists[pindex]); pcp->count += 1 << order; but I haven't caught a wascally wabbit yet after an hour of running xfstests. I think that's the only place we add a page to the pcp->lists.