Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2484158pxj; Mon, 10 May 2021 04:12:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJywkmYD5tzAdT9e89gerWLTbCouLN2gPjdcnpKAgKKB8ENtYbsJrTVp/MHq6K+h5ZQ8ZcdY X-Received: by 2002:aa7:c84a:: with SMTP id g10mr12812682edt.326.1620645145459; Mon, 10 May 2021 04:12:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620645145; cv=none; d=google.com; s=arc-20160816; b=VJGBGLHZ3NMsV+9/EOFcQgg32fEy6J34T3DqB9u6mh6DGWIdsdnQQ9snS0HYXqbJVU Rhp7eP9yeHBuzZpI9lZV8FCq4s8oyzQnLa8njO/8dw6DVQh7bLc2DN7QPveQU82eS7l2 NLFNAylViwVdPp+Y9fv1tjymJ8N99l7zNS/hj+HKVZ6f2NTxNQktp/Tsc27nPYiHEG7y 55u3gsoQm1c1npaJlvTN3B1XyqEzIacbwCmFJV3smXRWmNXjjnPvcQyQWUSofQVnfx3h GrYkPC9j+EGLpuO8yB4hfUaCPnw/2TopSRk6APanhnc3F3XC/tfHv28piHvmJRk5CriN X9Qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=y4wiTZaVGPpN+FjJ03mhuSqFJn90kQghS8cpKnE8Yd0=; b=qu3t8yAS9ezuc/f2ItWRYx/xw7nTX9Hlu4monHkW3dVkdO1oNPldRoEeRPFiYNfXDt yEjvxbCmhp73vyWXIuz5ctrB8bHtj4usp0w3UQX+Mx/m32D5/4p6Y2ljOtCNLEBFyiN+ gtA+Uh9iW82jqA1byFtB3cp0NIdF77OmUBfpbSaMT1FpH6A2Q96BxdSPy95Fa9XbelV8 nu6e5NQglqIZb6lPm0AwaQpmb54IpnEbbEzMJxzaxdZTwl/2HUH47ISEsquUp0yOmgeO FlrDPal/ZSvE36mxGPrU5C3ReUt4yVP5NZoh5fZV41evf+Jf8FqIftXrVnrqOr8uO7Sh yLYw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=olm1l8rH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v29si12729093eda.308.2021.05.10.04.12.01; Mon, 10 May 2021 04:12:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=olm1l8rH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236537AbhEJLIQ (ORCPT + 99 others); Mon, 10 May 2021 07:08:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:59618 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230430AbhEJKrs (ORCPT ); Mon, 10 May 2021 06:47:48 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id EE818619C0; Mon, 10 May 2021 10:37:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1620643062; bh=3kj4PJO8ex25VlM44hatwOl/Lp8XInGFtr40JCTQWx0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=olm1l8rHvemgo8sNmU792jqahGNc68gFGyVmC4+SDYoerVHwOhx9Ajpv2iUPvD484 ZzVwjso2FTVsgvTof4N1rUL4ADZVzS2k20VKBI41bGRRDfBk7AzSYAviIFt0u0VMxp C7PtOm+BOcmnQycOty3i7NsbpjRYwBD1r+klEWEY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Uladzislau Rezki (Sony)" , "Paul E. McKenney" , Sasha Levin Subject: [PATCH 5.10 127/299] kvfree_rcu: Use same set of GFP flags as does single-argument Date: Mon, 10 May 2021 12:18:44 +0200 Message-Id: <20210510102009.172462871@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210510102004.821838356@linuxfoundation.org> References: <20210510102004.821838356@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Uladzislau Rezki (Sony) [ Upstream commit ee6ddf58475cce8a3d3697614679cd8cb4a6f583 ] Running an rcuscale stress-suite can lead to "Out of memory" of a system. This can happen under high memory pressure with a small amount of physical memory. For example, a KVM test configuration with 64 CPUs and 512 megabytes can result in OOM when running rcuscale with below parameters: ../kvm.sh --torture rcuscale --allcpus --duration 10 --kconfig CONFIG_NR_CPUS=64 \ --bootargs "rcuscale.kfree_rcu_test=1 rcuscale.kfree_nthreads=16 rcuscale.holdoff=20 \ rcuscale.kfree_loops=10000 torture.disable_onoff_at_boot" --trust-make [ 12.054448] kworker/1:1H invoked oom-killer: gfp_mask=0x2cc0(GFP_KERNEL|__GFP_NOWARN), order=0, oom_score_adj=0 [ 12.055303] CPU: 1 PID: 377 Comm: kworker/1:1H Not tainted 5.11.0-rc3+ #510 [ 12.055416] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-1 04/01/2014 [ 12.056485] Workqueue: events_highpri fill_page_cache_func [ 12.056485] Call Trace: [ 12.056485] dump_stack+0x57/0x6a [ 12.056485] dump_header+0x4c/0x30a [ 12.056485] ? del_timer_sync+0x20/0x30 [ 12.056485] out_of_memory.cold.47+0xa/0x7e [ 12.056485] __alloc_pages_slowpath.constprop.123+0x82f/0xc00 [ 12.056485] __alloc_pages_nodemask+0x289/0x2c0 [ 12.056485] __get_free_pages+0x8/0x30 [ 12.056485] fill_page_cache_func+0x39/0xb0 [ 12.056485] process_one_work+0x1ed/0x3b0 [ 12.056485] ? process_one_work+0x3b0/0x3b0 [ 12.060485] worker_thread+0x28/0x3c0 [ 12.060485] ? process_one_work+0x3b0/0x3b0 [ 12.060485] kthread+0x138/0x160 [ 12.060485] ? kthread_park+0x80/0x80 [ 12.060485] ret_from_fork+0x22/0x30 [ 12.062156] Mem-Info: [ 12.062350] active_anon:0 inactive_anon:0 isolated_anon:0 [ 12.062350] active_file:0 inactive_file:0 isolated_file:0 [ 12.062350] unevictable:0 dirty:0 writeback:0 [ 12.062350] slab_reclaimable:2797 slab_unreclaimable:80920 [ 12.062350] mapped:1 shmem:2 pagetables:8 bounce:0 [ 12.062350] free:10488 free_pcp:1227 free_cma:0 ... [ 12.101610] Out of memory and no killable processes... [ 12.102042] Kernel panic - not syncing: System is deadlocked on memory [ 12.102583] CPU: 1 PID: 377 Comm: kworker/1:1H Not tainted 5.11.0-rc3+ #510 [ 12.102600] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-1 04/01/2014 Because kvfree_rcu() has a fallback path, memory allocation failure is not the end of the world. Furthermore, the added overhead of aggressive GFP settings must be balanced against the overhead of the fallback path, which is a cache miss for double-argument kvfree_rcu() and a call to synchronize_rcu() for single-argument kvfree_rcu(). The current choice of GFP_KERNEL|__GFP_NOWARN can result in longer latencies than a call to synchronize_rcu(), so less-tenacious GFP flags would be helpful. Here is the tradeoff that must be balanced: a) Minimize use of the fallback path, b) Avoid pushing the system into OOM, c) Bound allocation latency to that of synchronize_rcu(), and d) Leave the emergency reserves to use cases lacking fallbacks. This commit therefore changes GFP flags from GFP_KERNEL|__GFP_NOWARN to GFP_KERNEL|__GFP_NORETRY|__GFP_NOMEMALLOC|__GFP_NOWARN. This combination leaves the emergency reserves alone and can initiate reclaim, but will not invoke the OOM killer. Signed-off-by: Uladzislau Rezki (Sony) Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin --- kernel/rcu/tree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 5dc36c6e80fd..8a5cc76ecac9 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -3386,7 +3386,7 @@ static void fill_page_cache_func(struct work_struct *work) for (i = 0; i < rcu_min_cached_objs; i++) { bnode = (struct kvfree_rcu_bulk_data *) - __get_free_page(GFP_KERNEL | __GFP_NOWARN); + __get_free_page(GFP_KERNEL | __GFP_NORETRY | __GFP_NOMEMALLOC | __GFP_NOWARN); if (bnode) { raw_spin_lock_irqsave(&krcp->lock, flags); -- 2.30.2