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 4BA02C02198 for ; Mon, 10 Feb 2025 11:46:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B48EC6B007B; Mon, 10 Feb 2025 06:46:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AF8916B0083; Mon, 10 Feb 2025 06:46:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E7BA6B0085; Mon, 10 Feb 2025 06:46:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 835A26B007B for ; Mon, 10 Feb 2025 06:46:50 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 00098A0B40 for ; Mon, 10 Feb 2025 11:46:49 +0000 (UTC) X-FDA: 83103858138.12.7E9834F Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf02.hostedemail.com (Postfix) with ESMTP id 620BE8000F for ; Mon, 10 Feb 2025 11:46:48 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=gJkv4biH; spf=pass (imf02.hostedemail.com: domain of frederic@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=frederic@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739188008; 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=Ps66n9ZSqB4zxk6m4aSewUpKpYy0aIb7Fix6sYJ26/Y=; b=cr3JIRpldTbL554jtYFq+E081PIH2ms7HezLst/AUIiK9DY+UaasvdBoB8FTV+TmtP7ft5 Os+NyUpG2MT6bB1iYZp/jKQ0uDNIaovSZK0sn8d2CwcW2YboMWwWMi8Il5Gljfku7m7sC5 aj9bXCUcv39zhs8hUrMTyP175XI24y8= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=gJkv4biH; spf=pass (imf02.hostedemail.com: domain of frederic@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=frederic@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739188008; a=rsa-sha256; cv=none; b=aD/8rbEOv79lLnfLd893xM/4Rzz1tgo+H/kDR7J9Ku0x500Z2DA03mviOJK1ZbKu0fBo+o Q53+D4nN/CKsvLvyraW8D9QcRfiNd1iFyVocdpQAovaDcVtelBpVkdtC5esrajPO33HfbX buiv+8d48i+MHTNeLme1l3/ZupVmnRk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 1069EA411F9; Mon, 10 Feb 2025 11:45:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 06133C4CED1; Mon, 10 Feb 2025 11:46:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739188007; bh=eNTpsAJhLALvxRd0NaX/jpg1TUnh6W/8SH2xQ8wggr4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gJkv4biHjaeHXaG/QR8gKwCbXflI5PUDYBm55bAuUpuV7zUXqEFHWNztkKJBbVoSJ YVoANOBxvENm25SPqWWXLXm3lOT5WAByGDv6kW13qo9yrMlTRAGV/beF5eGQc+1IAk fGXiD1GaTk60KNcyni8YyVPkmubGL6xy+Nth1x9ZgCIp+3kCHbLiySqeB8YPuv19Zc jAr0jTqpCTSnfLXQhP4TGokcrTEUaN6xCj5HUESzXnFu26c9Tb5ChG84Mi5CiOiBQA BEgGLu5zVgVlaPW6wDn6RVRXCwFtrpV8mOHD/rUeqIHL68vcZNyySer7A8gHm9hIAp 2q7XbNyQPF3Sw== Date: Mon, 10 Feb 2025 12:46:44 +0100 From: Frederic Weisbecker To: Hillf Danton Cc: Marcelo Tosatti , Andrew Morton , Michal Hocko , linux-mm@kvack.org, LKML Subject: Re: [PATCH 6/6 v2] mm: Drain LRUs upon resume to userspace on nohz_full CPUs Message-ID: References: <20250209223005.11519-1-frederic@kernel.org> <20250210105028.2134-1-hdanton@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250210105028.2134-1-hdanton@sina.com> X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 620BE8000F X-Stat-Signature: w4nuegpy7as6cb5zsajrmqopyykuz1uk X-HE-Tag: 1739188008-956074 X-HE-Meta: U2FsdGVkX19LEk54XPitkS/objB4e60n2BrMfcMgC/dsTzBjATHqL4dm0W/u3Y+8YHgMTRwEGJSmlmqJp6N0/V+kDazfISzVJSpkbNqk+ZZiDZzrgFWs4akTttT3k8KS1EPuqWXoSnoRXafTAywtlevawt6usY5fj5izvlzmeji1whWfS/qCDKSdg1fjN9ergwqoXVBXYyZ5NMbvTWAJrWgFC2/iLRP3yurfTXZWBHXJIp3BaAS+D8pEH3xqO0f1VaSeQT6s0tJr1Q5B4QEIAxTZx5gJw27SvIyv7bpcvNBZamHMZ70VH+Ed9m9SYVyWza+itAb1faVLDBWhNRK+MjeJrAjgsHhhv6U7bTsJDKzcfCRAlEgz/Ixahar5kFPbL7y747wtbv5cCAP4dwG3u3xbZcv4Sx39NjJivWztPtluTNBU4L7goapvv/7HOxm6nei/dXBcNUjoM43QpOAlhY0bb43Tahdjq8wwNVtpZpMnhcSk3ZJmJsTFTOfaeagquqRfGdeGVF3WkQYCo38L0sx6NSCZkj9uxcNxBV7xzBROxBnntY378cRajcVQeYfqLw3xSFQR/ixGT1EhWoZPujEWr3kwxwX9JX/rWFf/ns05VygpN9bni6xA4LMKI3dYuMO/Mvcu8RkVEG5IVekgq70uEL85w8zLHQaMgouBfh8CDHzcxipuiGJEfWbZSnNJCpf+c7WxlogjVDw/KH5DX5Qylz3TrIixHLfqtt94rf0v7uHqv5uKKqUWwlyeX48K5LRygZm0kagsqaqrfMmAGoLgIzXm+06r1jirzMgUC8CBszSXUGsZFHnVBjhW/MjLnTVKcjfQ7YuViUE5+SQA2E725okN8XE1uEBIblUZn1ePXCScdOAEraj6v69NhehVUxRDqlD8v/R4xunkMVrnFZ+yuSw5m1TSlkuGD7tXPNuAU/mZl/Tt8xcE6tJ01ESdmXqi5yDmXCyzEwqe6LK 1KRui0A2 RQ49LFLluA4brUVs3HfdXBcKWPOWLHcTJihXQi+GUg2vR8uauS/fAe9Y1hl4x8GcXNYbYfRrUrMe1GmBrp01kQrxvEMFQNrW2OVWvqiMLak2par8WYqKLXkU8SGInYgaGnYq7j9paLlsJJtrAaeitYel6RYGDYWS0hyzf2YHAkRQ9yNE0ONH75Yu4kszVXuZxWQA8vvJhTcSx7ukPf7DbcO9KHbBvBadWrxAjzBdoBGRiuc/2FhrLubT68Lf0qZS4t8oaLRgWjFsSQSyq6SWHS3hwKOfzolRAmCsSCpygl8A7QrFtdoQTyYWdag== 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: Le Mon, Feb 10, 2025 at 06:50:26PM +0800, Hillf Danton a écrit : > On Sun, 9 Feb 2025 23:30:04 +0100 Frederic Weisbecker > > @@ -769,6 +772,9 @@ static bool cpu_needs_drain(unsigned int cpu) > > { > > struct cpu_fbatches *fbatches = &per_cpu(cpu_fbatches, cpu); > > > > + if (!housekeeping_cpu(cpu, HK_TYPE_KERNEL_NOISE)) > > + return false; > > + > > /* Check these in order of likelihood that they're not zero */ > > return folio_batch_count(&fbatches->lru_add) || > > folio_batch_count(&fbatches->lru_move_tail) || > > -- > > 2.46.0 > > Nit, I'd like to add a debug line to test your assumption that > isolated tasks are pinned to a single nohz_full CPU. > > --- x/mm/swap.c > +++ y/mm/swap.c > @@ -767,9 +767,10 @@ static void lru_add_drain_per_cpu(struct > static bool cpu_needs_drain(unsigned int cpu) > { > struct cpu_fbatches *fbatches = &per_cpu(cpu_fbatches, cpu); > + bool yes; > > /* Check these in order of likelihood that they're not zero */ > - return folio_batch_count(&fbatches->lru_add) || > + yes = folio_batch_count(&fbatches->lru_add) || > folio_batch_count(&fbatches->lru_move_tail) || > folio_batch_count(&fbatches->lru_deactivate_file) || > folio_batch_count(&fbatches->lru_deactivate) || > @@ -777,6 +778,12 @@ static bool cpu_needs_drain(unsigned int > folio_batch_count(&fbatches->lru_activate) || > need_mlock_drain(cpu) || > has_bh_in_lru(cpu, NULL); > + > + if (!housekeeping_cpu(cpu, HK_TYPE_KERNEL_NOISE)) { > + VM_BUG_ON(yes); > + return false; > + } > + return yes; If the task isn't pinned then the guarantees of nohz_full are broken anyway. Also if the task migrates it will simply execute the work elsewhere. My only worry is kernel threads. Those are simply ignored in this patchset but this is not right as they can do allocations. Yet they can't execute anything on return to userspace... Thoughts? Thanks. > } > > /* >