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 D9D1AC36014 for ; Fri, 4 Apr 2025 13:14:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE2FF280005; Fri, 4 Apr 2025 09:14:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D6A1B280004; Fri, 4 Apr 2025 09:14:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE64E280005; Fri, 4 Apr 2025 09:14:55 -0400 (EDT) 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 9ACD8280004 for ; Fri, 4 Apr 2025 09:14:55 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A983B1A010B for ; Fri, 4 Apr 2025 13:14:56 +0000 (UTC) X-FDA: 83296406592.22.973679B Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf01.hostedemail.com (Postfix) with ESMTP id 14FDF40007 for ; Fri, 4 Apr 2025 13:14:54 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hyaqClao; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf01.hostedemail.com: domain of frederic@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=frederic@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743772495; 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=SvBOHRFWqZ5gA3uJlo7062xICeasmOesknpVATQEc7w=; b=sMofEZPGPTe/sEKKWbn7qtvecDvGeKUojdXLBoplGe6a0JVqYDYl7GaFw9OT7Z3dwGJy/v f+ehFTkTsV+ToRupVSXSRqtt9wzOTEiyYgShhct04a4dSEcz6ForbjKKQB1l1YBUSnUm+G klCNf6oWr1vJZJKmr9OJ7No5eQk7CRQ= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hyaqClao; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf01.hostedemail.com: domain of frederic@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=frederic@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743772495; a=rsa-sha256; cv=none; b=nwtdon0oBUwk57PS7a1ck1tQrFW3OOzxEpjRDEC27wjfw0+widZ7F9rwHwmhc+L05TDQ/B +9sfvRjyUU8QABAtEPMOAlCMHg8KOQBvipCH8xylvUHbOyW14UQWoRJ8nTaba5/ITv87kk zO6deQHqMOp3a/rnFYsx5PPRCQzXCyk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id CD69A61127; Fri, 4 Apr 2025 13:14:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8FB3BC4CEE9; Fri, 4 Apr 2025 13:14:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1743772493; bh=HeMqPvb1y2aCZxnFmTUvOeSLlGPoM2Uq7DhtRctHdPM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hyaqClaoAvgGLSBSFqkKUIeAXoZNtabo4QFIr7icoqOcDhSx0srMht0EMknxzI7Tj YGivCGyRgpZDdjxPldT806SUIxKS4O4ZN/QCWpYCNiK9KjCyIi/RIbug/Vqj4Sh2/7 /OdvwUyX3aJOdlUq3SuOTUbEWRo6bOAiGQgqVhHc71nH12YL3BEZb9H+e5Z78QanoT WWj8Tbimd/EZZIMV/zXD4gbcAbjZTuXSlrNkHOgDekDT7w7vR9VG7Jf4UI3NUOoYdN mg1gNq9cIC6SLrPdOwuAtZthPJtZ3XcDkaGzvN4lG+C8Eh4jQdivxse6ZGz8TWm9Eb l7u1trDkt6vBQ== Date: Fri, 4 Apr 2025 15:14:50 +0200 From: Frederic Weisbecker To: Michal Hocko Cc: LKML , Peter Zijlstra , Ingo Molnar , Valentin Schneider , Marcelo Tosatti , Vlastimil Babka , Andrew Morton , Thomas Gleixner , Oleg Nesterov , linux-mm@kvack.org 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> <20250209223005.11519-7-frederic@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 14FDF40007 X-Stat-Signature: iejzzz6u1eoh8k4es91g9xmncm5nsp7k X-Rspam-User: X-HE-Tag: 1743772494-398530 X-HE-Meta: U2FsdGVkX19GspvT4X8+dgcSFsn9FCiuvz2VzlDMlfiV6GqRHowCarybprVDRwdHZdyDe6jkaMXisG4koc6cKNxDj0B+7CfehQZYtwPElARRh7tkOrQdkB+Q+xtdB7VVXIDFumIJl98zdFYw28rhP1BeeEQ7f+6DY8CHesfIKGyGHNmwxXDuBuomXuASCFu/ykpwbfBFIWOgWQxhzuYVTllC0AToOCemm8VLs6+sKiASqaunaQ14ZZUBQXwcbv1HQj7qbhQMFasHKLypQ1+ZJGcRQ1hXy4CqZpGhOOcBBpq8pT0VJ51ahLyRwBz0CQI0Er/VdHZNYPQBas+YA/MzAgaYv6E1BbKNPDFcEibtAgN354bn4+A93jGeYnjBtgFBwClRV9FS59BPnsCijvHdxqLCLrg7BXsfSh+kd0la9Oz/1JDYMw7qHLapLN87HKxFAyYt/d78ifBBO6cxu9xDr45XzeMIUgx3jJDyVHF2nb2GtwAH/EOy/x+nGzJi2VRLXaK2eqOcvaDYMnb6vY6shbzVYj6N8Uc/XMhc/qVd73tjm8lC1lv0mmuxbBbFEAHkJGPHAs1nS7yRPU5NCGJEFkSWum9hLt1pDY1v9IDzVoVGX7zqx9l/+gSj2iz9eT6VAWXxL9p5kGDmCrbgTmhhOSr+2O4xhCZmgIsg7iSnw1miNMmdaXGEyMYnCsNHsVyocHi7sMrS5XfA+ufmprZKgjPY4t18WnLb1oUsVq+72JkiFvRfKhC/ZTVpZg0wY1whPt/SO5cYPxCoidlYjJS/hmp1BOBTJhdKBw+3A+rNiqjUWJfmlIJIRtPA3ibBlYJu5BHvtrFi88ue3c298LE3VAPbC6INmS/nTK8B3Qgil57YNKnSFQ6GWqnMJD5/yFTnmjOSeDGaV6nlnA7ZDNAN1P9lE/HbQ0ifYOX8cb9wlGhmhMPPSiQjOLZBh674qmz4gDP7gwEjvZbxGbUbrtV fZJGnbQi rxzg8t4Ys/WuTPcLe0lrRGxQ8IEwV3SvTY6jOUEWWd1ziBuQbqLH8DrKu7hwOZQsCJHbI11/5zG1pLkpZOp460H4cXgS5LfpJRomdkvcL0fVclaQ3QrECFJtvs1WEiM4XN1sj5Lg7gM/3vUmnVZG38yYkb2PZisLgOWWv6Gac/x6ErGRG9tM7njMJIBGN+prytfq72shSPyqneC8RuTfmb6cOoCnn5etaiMzBfNcDmNm+HkPRNQEY4unhRBVRKPyhmudFFP5m2KwhSo2YpPgSh/NrtITpt+qvDgvq 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 Tue, Feb 11, 2025 at 12:42:51PM +0100, Michal Hocko a écrit : > On Sun 09-02-25 23:30:04, Frederic Weisbecker wrote: > > LRUs can be drained through several ways. One of them may add disturbances > > to isolated workloads while queuing a work at any time to any target, > > whether running in nohz_full mode or not. > > > > Prevent from that on isolated tasks with defering LRUs drains upon > > resuming to userspace using the isolated task work framework. > > I have to say this is rather cryptic description of the udnerlying > problem. What do you think about the following: > > LRU batching can be source of disturbances for isolated workloads > running in the userspace because it requires kernel worker to handle > that and that would preempt the said task. The primary source for such > disruption would be __lru_add_drain_all which could be triggered from > non-isolated CPUs. > > Why would an isolated CPU have anything on the pcp cache? Many syscalls > allocate pages that might end there. A typical and unavoidable one would > be fork/exec leaving pages on the cache behind just waiting for somebody > to drain. > > This patch addresses the problem by noting a patch has been added to the > cache and schedule draining to the return path to the userspace so the > work is done while the syscall is still executing and there are no > suprises while the task runs in the userspace where it doesn't want to > be preempted. Much better indeed :-) > > @@ -376,6 +377,8 @@ static void __lru_cache_activate_folio(struct folio *folio) > > } > > > > local_unlock(&cpu_fbatches.lock); > > + > > + isolated_task_work_queue(); > > } > > This placement doens't make much sense to me. I would put > isolated_task_work_queue when we queue something up. That would be > folio_batch_add if folio_batch_space(fbatch) > 0. Ok I moved it there but why doesn't it make sense also when folio_batch_space(fbatch) == 0, doesn't it mean that folio_batch_add() still added the entry but there is just no further room left? > > > > > #ifdef CONFIG_LRU_GEN > > @@ -738,7 +741,7 @@ void lru_add_drain(void) > > * the same cpu. It shouldn't be a problem in !SMP case since > > * the core is only one and the locks will disable preemption. > > */ > > -static void lru_add_and_bh_lrus_drain(void) > > +void lru_add_and_bh_lrus_drain(void) > > { > > local_lock(&cpu_fbatches.lock); > > lru_add_drain_cpu(smp_processor_id()); > > @@ -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; > > + > > Would it make more sense to use cpu_is_isolated() and use it explicitly > in __lru_add_drain_all so that it is clearly visible - with a comment > that isolated workloads are dealing with cache on their return to > userspace. No because cpu_is_isolated() is also true when the CPU is on NULL domain (isolated cpusset partition, or isolcpus=domain). And not all workloads want the possible overhead of scattered batching after every syscalls. Thanks. > > > /* 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 > > -- > Michal Hocko > SUSE Labs