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 8A2FDC47258 for ; Sun, 28 Jan 2024 06:35:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9DD5B6B006E; Sun, 28 Jan 2024 01:35:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 98CAA6B0071; Sun, 28 Jan 2024 01:35:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 87C136B0072; Sun, 28 Jan 2024 01:35:45 -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 78EBC6B006E for ; Sun, 28 Jan 2024 01:35:45 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id F3A5C4044D for ; Sun, 28 Jan 2024 06:35:44 +0000 (UTC) X-FDA: 81727759008.19.A2E7043 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf30.hostedemail.com (Postfix) with ESMTP id B467E80006 for ; Sun, 28 Jan 2024 06:35:41 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Irg0zpC+; dmarc=none; spf=none (imf30.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706423743; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=NUnz1RMN/0D0LFDxgrSiED0Vho/TqpFn9Fpqyv+1XrU=; b=Bx7pBL/dqGJmgeInLMMdhXowwv1dgd/CWUe+BZ6rcNRl8zdFcB4VZE0AnoEFs1BRDoe5QR SikLjKFgMyBtGJ0inWvlKFlhIeXfs0I4vS5it6qjLBcNCK18KFlfDKOi5LGRlyCeXOgdmf q2hPV5psx96LrO0S9K5qy2k8I9lFktM= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Irg0zpC+; dmarc=none; spf=none (imf30.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706423743; a=rsa-sha256; cv=none; b=5z9AMb59Oxzg0tBxhGbZ8pXJ7bV1/hSliI2CGT6X5eHTBMi67soiNOocFmf0Z4qAzNd8th gy88h+qBvblFXXYF/zWA7NhaMJ/+hWdVZHSr8j3oDjb8er1IvI1zvzYD6m5GJ4AuDRIf0m ckFlgoUm7PU8bbhpBI1nrjblerbprUo= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=NUnz1RMN/0D0LFDxgrSiED0Vho/TqpFn9Fpqyv+1XrU=; b=Irg0zpC+YpxRLe0gWjljAgl3wQ UiqYDmGyFeTAAIq1XcLQ4W9GjJ08UbUGUqUDqETWgrhvvEtFrtHxLfGsQsNNuFYWQhiAFN1GyhzD3 8XbbzRqZLqD6YNYqW3wfeq5jYt0tPfHp+RMgq6d5Nf33saLXCjjL1oxhqp9PcYdS3fevfHo+/Lbp/ 4RZI1BQ/IOqv0Lq1zZrcOz8+LXLy0cVC7T4DGamwC/U4fERd6f5h25AdTod3ak/mamiQZ0hk4zrVR tybEHAz0YtTZtsqXBxcKLzFZshgoSKaWF3h3O3JTCGMyotQyHFhujZquictNbxvnRg60EsQX+UkHp 6diIo4Jg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rTylU-00000002HtH-3YLR; Sun, 28 Jan 2024 06:35:36 +0000 Date: Sun, 28 Jan 2024 06:35:36 +0000 From: Matthew Wilcox To: zhiguojiang Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, opensource.kernel@vivo.com Subject: Re: [PATCH] mm:vmscan: shrink skip folios in the exiting task Message-ID: References: <20240124124308.461-1-justinjiang@vivo.com> <726d018c-01d0-48b3-870b-c63fb06eb0d0@vivo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <726d018c-01d0-48b3-870b-c63fb06eb0d0@vivo.com> X-Rspam-User: X-Stat-Signature: oui55ubttmca7hjiu1d9wwnmpd5kmyi5 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: B467E80006 X-HE-Tag: 1706423741-920064 X-HE-Meta: U2FsdGVkX19z9mjvUPNgdj++HVTUE3+Hc+l5ocnt9ZNpIqqpT06jMYnrgBs+bpj9bGOgV0z6w6LAIBG8WzQfPQtIcc1gofxzrfMAsfXW5/UQm7DA5MNetQEfI3vukUpyWr2yLGF/kOMET3zXyKVUKDbFDt2z5II1c6O507VJulS8je6DGNpGcYcjKyZ8zQVBsogg8Ybjv3Yj4dK5Qk36Vq5WnaQVvXVRiSBtIsSocmx9KLNYw4xJmi0j7aDrQ2B3WTmxiTXwJT570R/YrjfGJ4/cUXsqw6NX5LDbupsPG0sYbJTMeV19dlcL3Lfjz4PUForvgk0ZA+6J14hsZBvOEHkbj7avs7LWOYM+6s0ZlaJ0FDWAw5tjYe/fkvwpNzOrFrLWw/cypdTdMfpqkSRmfZBRJ5kIqOCOTWZVUjzuXrq70P7FNErdSa10lkTQVUgTFd3lIUTzLzvlGAYv5gm15tCSLWve3eK0sM+WTg6yqaWbu0xBmgEx6YW2+INCTKZtudHVcKW5pJ0r9fEz+Y9eld4+gbQjCTaNTb8/qejy2cQ+S/KxT3umMKxRVSkNqLz1azW6LuXT6vgmpt6xvWlAm4djVRWBCZSe+RtCh6yhlXLCZlf9+NOE1+qJphWtiLj+uuRupF9pBoXkCcADkkkErw01d7lem5GxsRpqwrmnWZD3mq5UWYn+ri5B/zSrsRhRtAN+RU7q4nQZUM3b0Ee6pR/TLXPsw5L3IcXWXqq3fYAM+PqwvI7a9xNSRQA3HeijON1SFp4Um3j+vwxE0HTDsWzHk6Lel/dClZJIyfkd0e4dpma0uhjZ7bKVI1n6iGdPWupAr5pQVu7SoM9w8cwy9dTDLWqm2XhYw0kiwqqYszMW1zGeR60fEl/Wz8kcRJVmiH3gTgL+IncjUKuXU9R71WilokJrUmWxJ2Ezm8u5Ly8O9vs4E9XG/nIo6/ciSmScGsmHkdyU9Je85kio/zE Rr0okQ9G 9jNymcLx63OojOIiMJv6bKRaYwZzJXea3tOWG3rdYfeSqoXKWjdSfsxJg9U0QGZ3Nb6I4Wc0wtHnqeVpqRTLJRyWn+Js6Tyga/k5iY5lU1YU/ujENsyUDgE4F7RFckCFYvBSRvA3KOpy4vaY= 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: List-Subscribe: List-Unsubscribe: On Thu, Jan 25, 2024 at 09:34:53AM +0800, zhiguojiang wrote: > > > In the scenarios of the low memory system and mutil backed-applications, > > > the time-consuming problem caused by shrinking the exiting task's folios > > > will be more severe. > > What testing have you done of this patch? How often does it happen? > > Are there particular workloads that benefit from this? (I'm not sure > > what "mutil backed-applications" are?) > 1 Yes, this patch has been tested. > > 2 When the exiting tasks and shrink_inactive_list occur at the same time, >    the folios which shrink_inactive_list reclaims may be the exiting tasks's > folios >    in lruvecs. And when system is low memory, it more likely to occur, > because >    more backend applidatuions will be killed. >    The shrink_inactive_list reclaims the exiting tasks's folios in lruvecs > and >    transforms the exiting tasks's anon folios into swap memory, which leads >    to the increasing load of the current exiting tasks. Ah, we're talking about an OOM scenario. OK, that makes some sense. You should have mentioned that in the patch description. > 3 This patch can alleviate the load of the tasks exiting process. This patch >    can make that the exiting tasks release its anon folios faster instead of >    releasing its swap memory from its anon folios swap-in in > shrink_inactive_list. > > 4 "mutil backed-applications" means that there are a large number of >     the backend applications in the system. > > Thanks > > > > And I do mean specifically of this patch, because to my eyes it > > shouldn't even compile. > Has been tested. That's odd. I thought GCC used to complain about long x = 0x100000000; but it does the right thing. Except on 32-bit where it'll say "warning: integer constant out of range". In any case, the number you chose is not going to work on 32-bit systems or on ARM or x86. It conflicts with protection keys on x86 and MTE on ARM. We can do it without any new magic numbers. I'm not sure this is a great approach, but this should work: +++ b/mm/rmap.c @@ -840,6 +840,12 @@ static bool folio_referenced_one(struct folio *folio, int referenced = 0; unsigned long start = address, ptes = 0; + /* Skip this folio if it's mapped by an exiting task */ + if (test_bit(MMF_OOM_SKIP, &vma->vm_mm->flags)) { + pra->referenced = -1; + return false; + } + while (page_vma_mapped_walk(&pvmw)) { address = pvmw.address;