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 0E94FC83038 for ; Tue, 1 Jul 2025 12:36:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 989D46B0096; Tue, 1 Jul 2025 08:36:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 960CD6B00AA; Tue, 1 Jul 2025 08:36:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89E036B00AC; Tue, 1 Jul 2025 08:36:55 -0400 (EDT) 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 7AA726B0096 for ; Tue, 1 Jul 2025 08:36:55 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 12BA91066FF for ; Tue, 1 Jul 2025 12:36:55 +0000 (UTC) X-FDA: 83615645190.10.393CB13 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf05.hostedemail.com (Postfix) with ESMTP id 461FB10000B for ; Tue, 1 Jul 2025 12:36:53 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=RrPWcxei; spf=pass (imf05.hostedemail.com: domain of frederic@kernel.org designates 172.234.252.31 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=1751373413; 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=qMkWzuIp0XSiJnheKqVh61L6275cQBYzeisPZUAppMs=; b=qRMo/P149Z/6/Z3EaA08heX3AP19R50V8Ntq31kgQ+FRZ269i4N6JdXbBmG8eYLg7j/inq riPzF/QwFrAdL/nIiXfa73sKym7cIsmw1Iv+LT6kIl0RlhjaZUknxlqcR4I4cvk9ny4kFE Id1aKQHdsifTvwzeP/2qLMKCpMkfWS8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751373413; a=rsa-sha256; cv=none; b=inc8qJyPTV3fvJSy1owP72/A8mhD+J4XnYGS0iNcuTYbS5QRVqjG8ltlM5AArB0WUACOun kLrKk8d4f7Rh5dWcSe3pK5jCsKHUKCXIQTfySxNG/5PVSePc5yT7Ws00c9WeDd05GJ0EQD 7ONUHJmjULwYHUuvQMyN9o3Kw/e04Bo= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=RrPWcxei; spf=pass (imf05.hostedemail.com: domain of frederic@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=frederic@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 3A4BC44535; Tue, 1 Jul 2025 12:36:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BBA0FC4CEEB; Tue, 1 Jul 2025 12:36:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751373412; bh=Yumc9AHeSxWJ3coM6Cuqca/8lTYWSOzPlXbAdw+pVFU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RrPWcxeixCM3W7sim7nZSuobUqXJHrON0fkntXopA5Io0TA/CMJSG13FGTOH2PMX3 aAVgwErG0tcoub1fBtUV+J+5SrdFOVRua3w2gs165x3aHnl06aPizxoZNABwRJH3QN 39oxikGCdAVhqHKaikTqlaP+lAMCIveu4dwlA2J9DpXiEPeqsDyI2/fS/vVfr4Wh/S x/WISXyRKhrSJibJiXp7MucQhqP7KXak4829yd1SgkZWfL/2j2ytIXwEPlDe3YIlcm zj3agkGp4sbWpgeZqgsP+1LfAKrmFSj1N1ySaivUlH5bIv/r8JUehXJ9HQrGs9LxJC DobUS98w2Cl+w== Date: Tue, 1 Jul 2025 14:36:49 +0200 From: Frederic Weisbecker To: Hillf Danton Cc: LKML , Oleg Nesterov , Michal Hocko , linux-mm@kvack.org, Marcelo Tosatti , Vlastimil Babka , Andrew Morton Subject: Re: [PATCH 0/6 v3] sched/mm: LRU drain flush on nohz_full Message-ID: References: <20250410152327.24504-1-frederic@kernel.org> <20250412025831.4010-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: <20250412025831.4010-1-hdanton@sina.com> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 461FB10000B X-Stat-Signature: cqr3gqgmxnznawei81agzbcg9otas4br X-Rspam-User: X-HE-Tag: 1751373413-72385 X-HE-Meta: U2FsdGVkX18MrRoI8B1aSHyQ2d/lVCCz2sfX+TmLBqVZb53mcBx0bcNPFwD5Wvd6ubJQKYIyJ+vwnkrsA0AshlZ7aFqCX6rtVYjWcJ8egAjVbzRM6mSdyhXUU/xMRwjuTrcIKs5+haXr/XijqQw6js/KT7XLK1MV+fmLuK8bq+/QhZIiuDsvuusgeFa7eO8AJmhCxq+o2jOK8h47ZQsiqlLtdiWkJMpuWW2plBwdRo2HzdYgt+Xg1URIaJ2IX/X0tCoOPXW2POS965kTvxvGOhQvSDje2j3qCR3XPc8EnN4iLLvIG42LP9BDQtN663XWxRHYKa5ERYSKgUamjdpDIqAWAmqoATaU/JI/s+UwQAPrdnAO0HEVQj5pFeUCiLzz2meSyetCPcPfBEAjPeUc7Fs08E7ERLuxuWv3PRNLTjmRbI85qYpKYRhNVb+HRIc0Ham+33wON8X/mFf/2GSPLPFNEhfMKrceM2bESsTg5IKzAay0Srq1DMeONs3/4gsXELUP8hI/jXyy3iyXZ7vd6Ixbe4LUiPFRQDhF2TQKYLDnazHigHL99NpTsXvCeZizOHKctXMyQEYQa7+KNuO9A/J//xTNE7wzsRZoPnj5IS78Vuj0PMeUM22ut1MoriwVT31po+Zgu1phMFTEcM1pIM/4YVpPJdNWh7mIDNt7jnCGEkhicWRR7ZiFnAfo7jYNJbY1Vt3rX6TQnqgUWTNhx4cE0qokZ5uuD4fwRl+5Ol1KwAJkugQsvyY4+DN4pwQjJPw55D00lPwhXdoe5vdaMcjVQql4Nu7TuSSFU2FRGX9vd1uwBH7aomNUj/2rQfiT6BZQWr3+Bv6fkS04g78AuTHAIJ6nnltQCQhjb+SQd7B19DrRlt/HLPvWg2Eu36KyypJz5KFdS24wusFf3chD11nd8VeBjTCojzeDhy3q3Syd087Xx/32eyQkqI9FE5lC3Mo4elsKVdCWsLOkLhR IFjGbJNk 8bkHEmLEUxiJTGdCap8HSoE95Po6qEuT8+pxzAftKwT3Je6F9Sm2bEaJX/OWm3WFHmNqnZAwI72QxYUj8QKzXCAxEyYJH6Y9a+UpyBmydYodNnjCbL6KDWXh5XaDEH6rQCbGIk8l3k6fpMLxyTLfbvA4UgawMvD0z5zpkJcO4Paa1NvkbzQYZ7wN0h4iYzuyGSBbS42/trdwbuph+lzR6n7d+XfuI7Qq3nh/N2J1AILKkKowJTQtUTks8/g== 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 Sat, Apr 12, 2025 at 10:58:22AM +0800, Hillf Danton a écrit : > On Thu, 10 Apr 2025 17:23:21 +0200 Frederic Weisbecker wrote > > Hi, > > > > When LRUs are pending, the drain can be triggered remotely, whether the > > remote CPU is running in userspace in nohz_full mode or not. This kind > > of noise is expected to be caused by preparatory work before a task > > runs isolated in userspace. This patchset is a proposal to flush that > > before the task starts its critical work in userspace. > > > Alternatively add a syscall for workloads on isolated CPUs to flush > this xxx and prepare that yyy before entering the critical work, instead > of adding random (nice) patches today and next month. Even prctl can > do lru_add_and_bh_lrus_drain(), and prctl looks more preferable over > adding a syscall. In an ideal world, this is indeed what we should do now. And I still wish we can do this in the future. The problem is that this has been tried by the past and the work was never finished because that syscall eventually didn't meet the need for the people working on it. I would volunteer to start a simple prctl to do such a flush, something that can be extended in the future, should the need arise, but such a new ABI must be thought through along with the CPU isolation community. Unfortunately there is no such stable CPU isolation community. Many developers in this area contribute changes and then switch to other things. As for the CPU isolation users, they are usually very quiet. I can't assume all the possible usecases myself and therefore I would easily do it wrong. In the meantime, the patchset here is a proposal that hopefully should work for many usecases. Thanks. -- Frederic Weisbecker SUSE Labs