Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp4116435rdb; Thu, 28 Dec 2023 10:35:16 -0800 (PST) X-Google-Smtp-Source: AGHT+IHos5SNpT+Hqvp9StF0dPIOkywTrTQyEdeHVQbAx+b2EOylyTwsiblOx+8W03dvlJDac2GH X-Received: by 2002:a17:902:7084:b0:1d4:9c20:4e2f with SMTP id z4-20020a170902708400b001d49c204e2fmr39393plk.22.1703788516045; Thu, 28 Dec 2023 10:35:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703788516; cv=none; d=google.com; s=arc-20160816; b=gRaUyTvM7t9e8mTasAnqY8/HD09+t0+wPRqs3sJXxyNkFlxl0n15NRD++rbdEIfLX8 aUZ5Hzq3+PinpHUaMUs1A99wjNDjCfWiNVmMan5dD1FIzUZipe3mDerk4OQU0Onm/Rwt 6ah+KQ6IYALGfDiwUljLsv776mq2coXa959llCwos5qf+OW1LCBLlNdRrmtE1RHB6/ZO 6gJueVkPP4YIhwA+2YxWOGFRHjrcvmjhOo6HXlkZBCBkO/cgXs3Siy9r1u+eMxQfV6kY knIYlQEQKsCHHmjR1xCWCW73OykBr3R2RfhJNLYL2dqyQEtrdVwyprY4KL0BdqlbZ2Bh Utog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:in-reply-to:subject:cc:to:from:date :dkim-signature; bh=1/77b2Fo/WnASYiduBv30c2nietHwLk6cCOepVkjJSY=; fh=WuLomYDyAW/aYAkZdiGMRXhA3UBMDOVvFe0bJPpPH3o=; b=jOliJy8h6dEdDPMI9mqB/p6ZFUi/LrbtqZIHYpDB0DdEBv0xQJFFq1FITNg5/KVF21 eZpVsUDhyC5raYCDCI4eOfTO2cYfgoij6uQGxKLOTmYPg2k0sS2brL9CxtyFotFQ186H +ysosNREKxtWYwQktTwKHtiegrMdnEqYKNajfdKRatkh2ky66kL+cwkrG/ax0v84wv42 p5OCBgypHE2BDTdEIAIw9qIpm1eZIZeFpUXUKQ5LACwhIUfbRBvK20FlaE9+1oxv2eIi o4qtUbd8VaI7w0ojj+yI3EZd7SO2cF4HFw8xggFqCiAUoFPuQ5ZSWHpL/6fSWK04Pdox sm2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@inria.fr header.s=dc header.b=HjqmiiZT; spf=pass (google.com: domain of linux-kernel+bounces-12824-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-12824-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=inria.fr Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id k9-20020a170902c40900b001d3735ea525si13577749plk.478.2023.12.28.10.35.15 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Dec 2023 10:35:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-12824-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@inria.fr header.s=dc header.b=HjqmiiZT; spf=pass (google.com: domain of linux-kernel+bounces-12824-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-12824-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=inria.fr Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 65E09B23C12 for ; Thu, 28 Dec 2023 18:35:11 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 97A89101C8; Thu, 28 Dec 2023 18:35:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=inria.fr header.i=@inria.fr header.b="HjqmiiZT" X-Original-To: linux-kernel@vger.kernel.org Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 71E70F9D1 for ; Thu, 28 Dec 2023 18:34:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=inria.fr Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=inria.fr DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=1/77b2Fo/WnASYiduBv30c2nietHwLk6cCOepVkjJSY=; b=HjqmiiZTv2q2YU85AyMEVB/SEo3SOIuQ7n3yCneGExTzhI4pMiHRQFm1 p1gWsxNncjnSiLRJgGAFwU1SnlU4Y+vwViBp5buMR4iBd2ao1vh7a7e8W C+9fm/JXE+dB9Lf+VPmMwQS3wIhKsk9F5sw2o17cGM19JxNYJgAQvJDiu o=; Authentication-Results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=julia.lawall@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr X-IronPort-AV: E=Sophos;i="6.04,312,1695679200"; d="scan'208";a="75470371" Received: from dt-lawall.paris.inria.fr ([128.93.67.65]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Dec 2023 19:34:48 +0100 Date: Thu, 28 Dec 2023 19:34:48 +0100 (CET) From: Julia Lawall To: Vincent Guittot cc: Peter Zijlstra , Ingo Molnar , Dietmar Eggemann , Mel Gorman , linux-kernel@vger.kernel.org Subject: Re: EEVDF and NUMA balancing In-Reply-To: Message-ID: References: <20231004174801.GE19999@noisy.programming.kicks-ass.net> <20231009102949.GC14330@noisy.programming.kicks-ass.net> <98b3df1-79b7-836f-e334-afbdd594b55@inria.fr> <93112fbe-30be-eab8-427c-5d4670a0f94e@inria.fr> <9dc451b5-9dd8-89f2-1c9c-7c358faeaad@inria.fr> <2359ab5-4556-1a73-9255-3fcf2fc57ec@inria.fr> <6618dcfa-a42f-567c-2a9d-a76786683b29@inria.fr> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII > > > > > > I'm surprised that you have mainly CPU_NEWLY_IDLE. Do you know the reason ? > > > > > > > > > > No. They come from do_idle calling the scheduler. I will look into why > > > > > this happens so often. > > > > > > > > Hmm, the CPU was idle and received a need resched which triggered the > > > > scheduler but there was nothing to schedule so it goes back to idle > > > > after running a newly_idle _load_balance. > > > > > > I spent quite some time thinking the same until I saw the following code > > > in do_idle: > > > > > > preempt_set_need_resched(); > > > > > > So I have the impression that do_idle sets need resched itself. > > > > But of course that code is only executed if need_resched is true. But I > > Yes, that is your root cause. something, most probably in interrupt > context, wakes up your CPU and expect to wake up a thread > > > don't know who would be setting need resched on each clock tick. > > that can be a timer, interrupt, ipi, rcu ... > a trace should give you some hints I have the impression that it is the goal of calling nohz_csd_func on each clock tick that causes the calls to need_resched. If the idle process is polling, call_function_single_prep_ipi just sets need_resched to get the idle process to stop polling. But there is no actual task that the idle process should schedule. The need_resched then prevents the idle process from stealing, due to the CPU_NEWLY_IDLE flag, contradicting the whole purpose of calling nohz_csd_func in the first place. julia