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 BF6CEC433FE for ; Mon, 21 Nov 2022 01:54:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F38D86B0072; Sun, 20 Nov 2022 20:54:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EE91E6B0073; Sun, 20 Nov 2022 20:54:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB0836B0074; Sun, 20 Nov 2022 20:54:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id CBF2A6B0072 for ; Sun, 20 Nov 2022 20:54:42 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 992B01201A0 for ; Mon, 21 Nov 2022 01:54:42 +0000 (UTC) X-FDA: 80155780404.06.499063C Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf25.hostedemail.com (Postfix) with ESMTP id E183EA000B for ; Mon, 21 Nov 2022 01:54:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1668995680; x=1700531680; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=QpFKF7fDLr8Ams9bU7P3h3OfOCC05+T00uayr9oKtx8=; b=GpCvKL7RjFUraewKmW4cmY8W42ticF+XN1aDt0soaLJ+OO3z1jQ1/QqS 7uBxI9c+sOgk4fKqiV+HjfwFxcwSjOjKu1osjz6oam3iC61xe+uqOdwEG 7bgR5GpTNfaVZrvOqbu4eV68PeBPPkzLPguuH4ZjEPDKw/h/Dfsk4HfGY AFHKTNQ7cGyUjCVjlOwjCzczC7PuYv8Bs4wsfNXEi936WplmCFsdGKg5t l3gUCygZ6wStDAm8nMNrjCVKh9mZEqi6eb2hNMEnoRIVjP5qrwam1nlHH 0WtX2WtEFDSSUk4svZ1UN+099wBMliCoF6Kai3NRaYZBsrEceZ2yCmhYm g==; X-IronPort-AV: E=McAfee;i="6500,9779,10537"; a="293842648" X-IronPort-AV: E=Sophos;i="5.96,180,1665471600"; d="scan'208";a="293842648" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Nov 2022 17:54:38 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10537"; a="746716085" X-IronPort-AV: E=Sophos;i="5.96,180,1665471600"; d="scan'208";a="746716085" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Nov 2022 17:54:35 -0800 From: "Huang, Ying" To: Chen Wandun , Andrew Morton Cc: , , , , , Subject: Re: [RFC PATCH] swapfile: fix soft lockup in scan_swap_map_slots References: <20221118133850.3360369-1-chenwandun@huawei.com> <20221118132741.aaf6f9081b5a1018cc9a5402@linux-foundation.org> Date: Mon, 21 Nov 2022 09:53:35 +0800 In-Reply-To: <20221118132741.aaf6f9081b5a1018cc9a5402@linux-foundation.org> (Andrew Morton's message of "Fri, 18 Nov 2022 13:27:41 -0800") Message-ID: <87ilj9ul7k.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668995681; a=rsa-sha256; cv=none; b=TUuV34KbjcKhJBWYzXv0x0cM+BTlUKSq9oieUsToHHPfg/7l+/XMGlaIzCqZ5UxfKb1XMO 8hsi0NrGJgefGK/YJo0FUu1AluBKKCzwgS6F1yjK4CTWN5wDJkn1TLfLRFBAm7WtLdT82f 4DmAifuxH9gSeWNo3TneMZjeANmRsGA= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=GpCvKL7R; spf=pass (imf25.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668995681; 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=jwe6IgGkDavIkyqB7tc+rCnmd54yDXz5AB59teMWnAg=; b=tOAsK9hR+1Hgh6Ay0KB9hFtdKSYY80/RHU3d40pYl/mlMND0/hj+N2SakXaY3360bg6A21 lllzlQbz0s0Zjv7JsfiQ1ANRZF2JCvdlo5ea1k36myQGyr6+F9m4pc1g3d5cbdySltEIOy RDi6FioYRCx9pvLF/2lA2anSE1tvNtU= X-Rspam-User: X-Stat-Signature: 917bg97cj78s9k5q7md6zd5xjej5sir6 X-Rspamd-Queue-Id: E183EA000B Authentication-Results: imf25.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=GpCvKL7R; spf=pass (imf25.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam07 X-HE-Tag: 1668995679-452602 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: Andrew Morton writes: > On Fri, 18 Nov 2022 21:38:50 +0800 Chen Wandun wrote: > >> A soft lockup occur in scan free swap slot by constructing >> huge memory pressure. >> The test scenario is: 64 CPU cores, 64GB memory, and 28 >> zram devices, the disksize of each zram device is 50MB. >> >> LATENCY_LIMIT is used to prevent soft lockup in function >> scan_swap_map_slots, but the real loop number would more >> than LATENCY_LIMIT because of "goto checks and goto scan" >> repeatly without decrease of latency limit. >> >> In order to fix it, move decrease latency_ration code in advance. >> >> There is also a suspicious place that will cause soft lockup in >> function get_swap_pages, in this function, the "goto start_over" >> may result in continuous scanning of swap partition, if there is >> no cond_sched in scan_swap_map_slots, it would cause soft lockup >> (I am not sure about this). >> >> ... >> > > Looks sensible. Yes. LGTM. Reviewed-by: "Huang, Ying" >> --- a/mm/swapfile.c >> +++ b/mm/swapfile.c >> @@ -972,23 +972,23 @@ static int scan_swap_map_slots(struct swap_info_struct *si, >> scan: >> spin_unlock(&si->lock); >> while (++offset <= READ_ONCE(si->highest_bit)) { >> - if (swap_offset_available_and_locked(si, offset)) >> - goto checks; >> if (unlikely(--latency_ration < 0)) { >> cond_resched(); >> latency_ration = LATENCY_LIMIT; >> scanned_many = true; >> } >> + if (swap_offset_available_and_locked(si, offset)) >> + goto checks; >> } >> offset = si->lowest_bit; >> while (offset < scan_base) { >> - if (swap_offset_available_and_locked(si, offset)) >> - goto checks; >> if (unlikely(--latency_ration < 0)) { >> cond_resched(); >> latency_ration = LATENCY_LIMIT; >> scanned_many = true; >> } >> + if (swap_offset_available_and_locked(si, offset)) >> + goto checks; >> offset++; >> } >> spin_lock(&si->lock); > > But this does somewhat alter the `scanned_many' logic. We'll now set > 'scanned_many` earlier. What are the effects of this? > > The ed43af10975eef7e changelog outlines tests which could be performed > to ensure we aren't regressing from this. Per my understanding, this will not influence `scanned_many` logic much. Because `scanned_many` flag will be set just a little earlier (one less slot). Best Regards, Huang, Ying