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 90EA9C4332F for ; Mon, 7 Nov 2022 11:16:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EEF856B0071; Mon, 7 Nov 2022 06:16:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E9F226B0072; Mon, 7 Nov 2022 06:16:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8D586B0073; Mon, 7 Nov 2022 06:16:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C8BFD6B0071 for ; Mon, 7 Nov 2022 06:16:53 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 9DCFAC0CEB for ; Mon, 7 Nov 2022 11:16:53 +0000 (UTC) X-FDA: 80106393906.23.B2B741E Received: from outbound-smtp55.blacknight.com (outbound-smtp55.blacknight.com [46.22.136.239]) by imf19.hostedemail.com (Postfix) with ESMTP id E13951A0008 for ; Mon, 7 Nov 2022 11:16:52 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail01.blacknight.ie [81.17.254.10]) by outbound-smtp55.blacknight.com (Postfix) with ESMTPS id 0EF03FA7AE for ; Mon, 7 Nov 2022 11:16:51 +0000 (GMT) Received: (qmail 22850 invoked from network); 7 Nov 2022 11:16:50 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 7 Nov 2022 11:16:50 -0000 Date: Mon, 7 Nov 2022 11:16:49 +0000 From: Mel Gorman To: Hugh Dickins Cc: Andrew Morton , Yu Zhao , Vlastimil Babka , Nicolas Saenz Julienne , Marcelo Tosatti , Michal Hocko , Marek Szyprowski , LKML , Linux-MM Subject: Re: [PATCH v2] mm/page_alloc: Leave IRQs enabled for per-cpu page allocations Message-ID: <20221107111649.rzfgqk3ebvicsuyw@techsingularity.net> References: <20221104142259.5hohev5hzvwanbi2@techsingularity.net> <97b7ae87-797c-4ebb-d2d3-9415975188@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <97b7ae87-797c-4ebb-d2d3-9415975188@google.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667819813; 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; bh=eFft468Y14iRbPn66NpGTaTxzNFjNZfsr6wR50dvfJU=; b=Zqqtww0DrtNWVn5eqo7TfuAWV936pYB8wPh2gb0aiycKfYOcfVch7TIzhx7dvN0/nthbuB dkJtApSp3x23oK2Y3HBm5dVUW/5JfVTJeVyfgWH2UvTGYqQSbMn9i2Dpl+tU0fl/XYbl7L AjRiyhDBpMWkWUd8KmEvszlqKwztKW4= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.136.239 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667819813; a=rsa-sha256; cv=none; b=dUT3T/2EUMqKy/gLzcrTaiUiizc9Fnqu5eE4bX1yV9M/xVX3y5yby/uUnuYk2LYaT5Ev7a P3F0FMhmv62X+Re0naGdZ+Fuf9VzLIHOPH/UzeEu+qoVbDD26yXlFZ7emMsr6+y8FQoDDT A0c3NGnuVVqJL4WmxeQ1NhywRo/F5QA= X-Rspam-User: X-Stat-Signature: 3qo8ctioq7mfmb8zh1mesm8c3rw5utew X-Rspamd-Queue-Id: E13951A0008 Authentication-Results: imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.136.239 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none X-Rspamd-Server: rspam07 X-HE-Tag: 1667819812-613691 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 Sun, Nov 06, 2022 at 08:42:32AM -0800, Hugh Dickins wrote: > On Fri, 4 Nov 2022, Mel Gorman wrote: > > > Changelog since v1 > > o Use trylock in free_unref_page_list due to IO completion from softirq > > context > > > > The pcp_spin_lock_irqsave protecting the PCP lists is IRQ-safe as a task > > allocating from the PCP must not re-enter the allocator from IRQ context. > > In each instance where IRQ-reentrancy is possible, the lock is acquired using > > pcp_spin_trylock_irqsave() even though IRQs are disabled and re-entrancy > > is impossible. > > > > Demote the lock to pcp_spin_lock avoids an IRQ disable/enable in the common > > case at the cost of some IRQ allocations taking a slower path. If the PCP > > lists need to be refilled, the zone lock still needs to disable IRQs but > > that will only happen on PCP refill and drain. If an IRQ is raised when > > a PCP allocation is in progress, the trylock will fail and fallback to > > using the buddy lists directly. Note that this may not be a universal win > > if an interrupt-intensive workload also allocates heavily from interrupt > > context and contends heavily on the zone->lock as a result. > > > > [yuzhao@google.com: Reported lockdep issue on IO completion from softirq] > > Signed-off-by: Mel Gorman > > Hi Mel, I think you Cc'ed me for the purpose of giving this patch a > run, and reporting if it's not good. That is the case, I'm afraid. > Thanks for testing and yes, you were cc'd in the hope you'd run it through a stress test of some sort. A lot of the test I run are performance orientated and relatively few target functional issues. > I first tried it on a v6.1-rc3, and very soon crashed under load with > something about PageBuddy in the output. When I reverted, no problem; > I thought maybe it's dependent on other commits in akpm's tree. > Can you tell me what sort of load it's under? I would like to add something similar to the general battery of tests I run all patches affecting the page allocator through. Even if this is just a crude shell script, it would be enough for me to work with and incorporate into mmtests. If it's there and I find mm-unstable has its own problems, bisection can brute force the problem. > Later I tried on current mm-unstable: which is living up to the name > in other ways, but when other issues patched, it soon crashed under > load, GPF probably for non-canonical address 0xdead0000000000f8 > in compact_zone < compact_zone_order < try_to_compact_pages < > .... < shmem_alloc_hugefolio < ... > 0xdead000* looks like ILLEGAL_POINTER_VALUE which is used as a poison value so a full list of debugging options you apply for the stress test would also be useful. > I do try to exercise compaction as hard as I can, even to the point > of having a hack in what used to be called shmem_getpage_gfp(), > reverting to the stronger attempt to get huge pages, before Rik > weakened the effect of huge=always with vma_thp_gfp_mask() in 5.12: > so shmem is probably applying stronger flags for compaction than it > would in your tree - I'm using > GFP_TRANSHUGE_LIGHT | __GFP_RECLAIM | __GFP_NORETRY there. > > Sorry for not giving you more info, I'm rather hoping that compaction > is relevant, and will give you a clue (maybe that capture code, which > surprised us once before??). While capture is a possibility, it's a bad fit for this patch because pages are captured under task context. > What I'm really trying to do is fix > the bug in Linus's rmap/TLB series, and its interaction with my > rmap series, and report back on his series (asking for temporary > drop), before next-20221107 goes down in flames. > > I'd advocate for dropping this patch of yours too; but if it's giving > nobody else any trouble, I can easily continue to patch it out. > Given that you tested the patch against v6.1-rc3, it's clear that the patch on its own causes problems. Having a reproduction case will help me figure out why. -- Mel Gorman SUSE Labs