Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp4604672rdb; Fri, 29 Dec 2023 07:18:45 -0800 (PST) X-Google-Smtp-Source: AGHT+IFQtvto69xfQhfUHQLlCpywX1AfCs5QNm5FYDHLGjKK/SBRMyT4Apl5JDhZACHF1E/acwjY X-Received: by 2002:a05:6a21:81a8:b0:190:8e40:6f2a with SMTP id pd40-20020a056a2181a800b001908e406f2amr12753612pzb.44.1703863124791; Fri, 29 Dec 2023 07:18:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703863124; cv=none; d=google.com; s=arc-20160816; b=itR7EbNmYBmNQdHcuVWqmBkE5LlVn1+BFLCNe7+kgCvlDXppTTGWkQvojpE8mNj0jw IWmfOa69h5X3Ac9mQU1DJHmRxI6kTWDBGuSeHWsquG9O+yOpUYY/imSOQnYHYQy6BCtp QzLWzQjL7bBGPJchlX40nhfPVefT3QZ6Yr4znnvK0rHIVyfgXfr6m2Fp/ZTEoKWFEBvx gOeEs3ztr7fT37TwyqxadTqP/xlkJgNoe9rYcF+5A1u9wbXIC1ogIYZkrX1xZFZUDHl0 luDJAhPKtdl02Sd7hIOo2aqeqHT37dNrL5Sa61sN6e4ZQs4DGb4JyLT+QgjUEUdY0AjY yHjA== 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=BO59ay58b+3H0q4MiJOf8mCVwTT90IGD/0wSgqjT9uc=; fh=WuLomYDyAW/aYAkZdiGMRXhA3UBMDOVvFe0bJPpPH3o=; b=ujsUvTXGZYiaG1sI4k8iL31tv6U8hyoOVOXrFLRJmFOPl940G+r+0syO1vUmZ2cfOA xDA0IE3tkWIxiA5Ou7yU15c+f6IlZAJ5bwpSdplki1MMcL/cylJTwFLwAoUOPmbjIRTU v5XMgB4daye2XMXRrCAGQppt1X2jH14CQbKNeBFSh6meMX8p+eE4i66yhryUgWRvwNyz vr5GKcpm8DkBHJh3JN6/DVlxmvTLq8ns3PEEIK2ce93Juq9FfyGmAXJZ+w3oETpuxwUs NLGYtMBhMBd2TEZjSpJVN/8rpZdF6iqsb5Ui4Ds4kVlR5DMks4BN19i8C1puuUJKhlOQ vX9w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@inria.fr header.s=dc header.b=bl3eD9EX; spf=pass (google.com: domain of linux-kernel+bounces-13134-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-13134-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 n128-20020a632786000000b005cdf88fbc11si12504867pgn.48.2023.12.29.07.18.44 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Dec 2023 07:18:44 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-13134-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=bl3eD9EX; spf=pass (google.com: domain of linux-kernel+bounces-13134-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-13134-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 B1651B22370 for ; Fri, 29 Dec 2023 15:18:41 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D0AD0125AE; Fri, 29 Dec 2023 15:18:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=inria.fr header.i=@inria.fr header.b="bl3eD9EX" X-Original-To: linux-kernel@vger.kernel.org Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 9BD81125A3 for ; Fri, 29 Dec 2023 15:18:30 +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=BO59ay58b+3H0q4MiJOf8mCVwTT90IGD/0wSgqjT9uc=; b=bl3eD9EXW1fFY03a3QeQo570zaXEj5RpUsoe9ogtj6CxcXQimeKbPEQS 6wZHmxnYA+l2ecFMnYl7vw5ufJIf4rWzvjjfxw68t/3KR5RbdpmvPqNix 4tW9vnzaTZrManLDPti3kNwxmEXkfhFfABkswt7HuOasAKbmEjTp/qIcB k=; Authentication-Results: mail2-relais-roc.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,315,1695679200"; d="scan'208";a="144313364" Received: from dt-lawall.paris.inria.fr ([128.93.67.65]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Dec 2023 16:18:23 +0100 Date: Fri, 29 Dec 2023 16:18:22 +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: <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 On Thu, 28 Dec 2023, Julia Lawall wrote: > > > > > > > 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. Looking in more detail, do_idle contains the following after existing the polling loop: flush_smp_call_function_queue(); schedule_idle(); flush_smp_call_function_queue() does end up calling nohz_csd_func, but this has no impact, because it first checks that need_resched() is false, whereas it is currently true to cause existing the polling loop. Removing that test causes: raise_softirq_irqoff(SCHED_SOFTIRQ); but that causes the load balancing code to be executed from a ksoftirqd task, which means that there is now no load imbalance. So the only chance to detect an imbalance does seem to be to have the load balance call be executed by the idle task, via schedule_idle(), as is done currently. But that leads to the core being considered to be newly idle. julia