Received: by 2002:a05:7412:98c1:b0:fa:551:50a7 with SMTP id kc1csp254691rdb; Fri, 5 Jan 2024 08:45:52 -0800 (PST) X-Google-Smtp-Source: AGHT+IFPC2CxthJwSvnMBEOEmLXoKhaq828pXXcHF13v86TAeNhfQ2NOKZfvObTfddztlPTq9DZ4 X-Received: by 2002:a17:90b:b03:b0:28c:8c68:e56e with SMTP id bf3-20020a17090b0b0300b0028c8c68e56emr2071452pjb.90.1704473152321; Fri, 05 Jan 2024 08:45:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704473152; cv=none; d=google.com; s=arc-20160816; b=uhRq7dTcUtpsLtFOcXDFdi42x8Nq0R/KeWKckeQ/3qsvR6uX/cau2HVoxiJviqmwcF nC0JS1g6xEVv815tCmHwm3MuminlhqJNbXZGROCdLZtEOoCpakydhQe39/vLpqSu6FjI kVHxCKyWoW4JbOSCpubOZCtSovOr0LRQwxWGtwwxKYG2WF9r0wPnU2w4Y2GCi4iEp0W6 PF7fGy5yvH2km4Hk7820myacGo5o3VWjDhVustLr8J7h4WcVs4FCOA7Z1wIIq8angHgt L0ePy7mfL2lcaD+tXWz0XD38pqIP1Z9nBiS20eu6oPs1LJbs30XNDYBNz1LL8ggpkROr hhzA== 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=s/faCPIBWWAvaUmdKVq+trIc4bCv1+1zq1kpz+PlqHk=; fh=WuLomYDyAW/aYAkZdiGMRXhA3UBMDOVvFe0bJPpPH3o=; b=day/Ez8BsknC8G3elSBvKgyF4LwF4XR6EvfI0ECjXWiSTJqDgvuQdW2BBWBRo5FBmV KMJXqcuFW6hHfI3sdzHfiqpsK+xPQQTM9g6LW7O8tuHxkb9HGLO4eqs9YKzumMSBsWQM LTS5+jNDJsrIwITq5RiNRZb2zKf90NY2J7OLRpe+DB55Ph7LcM/Uy2PuZLVwtRWcM2yw QN2ogY0LxG/iD9kPK0wVg9J3sSVZsK/c4bPTdF1+Iu06QrWg2f0WrxOqJAyKwlaZt0/v G6S0x+/708B5pXvZvq0geieLV5rQp3xc35ZcZgUu0AURmQio8lXTSag/xIbF/UvXr/w+ erBg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@inria.fr header.s=dc header.b="uBqCzq/r"; spf=pass (google.com: domain of linux-kernel+bounces-18077-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-18077-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=inria.fr Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id h18-20020a17090acf1200b0028c3ae07ce8si1062928pju.184.2024.01.05.08.45.52 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jan 2024 08:45:52 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-18077-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@inria.fr header.s=dc header.b="uBqCzq/r"; spf=pass (google.com: domain of linux-kernel+bounces-18077-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-18077-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 sv.mirrors.kernel.org (Postfix) with ESMTPS id 159E0287B1B for ; Fri, 5 Jan 2024 16:39:38 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9126D3219F; Fri, 5 Jan 2024 16:39:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=inria.fr header.i=@inria.fr header.b="uBqCzq/r" 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 086D032182 for ; Fri, 5 Jan 2024 16:39:14 +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=s/faCPIBWWAvaUmdKVq+trIc4bCv1+1zq1kpz+PlqHk=; b=uBqCzq/rja3i8rFqWi65EOUDVYse9EgajcTbqhC7NrbcQ6lZxsBvpC+4 Efaq7yRa+RLTF0AQ89xKczYBmzWvI/dslldXu7oadMASRck6H+ZWrGMW8 VJZ8Rva1mL0+xdEjA0hNtQcbAKPElRwMvsWUmhWmYip5YGClVtWc0G4lt U=; 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,334,1695679200"; d="scan'208";a="75972021" 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; 05 Jan 2024 17:39:12 +0100 Date: Fri, 5 Jan 2024 17:39:12 +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: <7a845b43-bd8e-6c7d-6bca-2e6f174f671@inria.fr> References: <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 Fri, 5 Jan 2024, Vincent Guittot wrote: > On Fri, 5 Jan 2024 at 15:51, Julia Lawall wrote: > > > > > Your system is calling the polling mode and not the default > > > cpuidle_idle_call() ? This could explain why I don't see such problem > > > on my system which doesn't have polling > > > > > > Are you forcing the use of polling mode ? > > > If yes, could you check that this problem disappears without forcing > > > polling mode ? > > > > I expanded the code in do_idle to: > > > > if (cpu_idle_force_poll) { c1++; > > tick_nohz_idle_restart_tick(); > > cpu_idle_poll(); > > } else if (tick_check_broadcast_expired()) { c2++; > > tick_nohz_idle_restart_tick(); > > cpu_idle_poll(); > > } else { c3++; > > cpuidle_idle_call(); > > } > > > > Later, I have: > > > > trace_printk("force poll: %d: c1: %d, c2: %d, c3: %d\n",cpu_idle_force_poll, c1, c2, c3); > > flush_smp_call_function_queue(); > > schedule_idle(); > > > > force poll, c1 and c2 are always 0, and c3 is always some non-zero value. > > Sometimes small (often 1), and sometimes large (304 or 305). > > > > So I don't think it's calling cpu_idle_poll(). > > I agree that something else > > > > > x86 has TIF_POLLING_NRFLAG defined to be a non zero value, which I think > > is sufficient to cause the issue. > > Could you trace trace_sched_wake_idle_without_ipi() ans csd traces as well ? > I don't understand what set need_resched() in your case; having in > mind that I don't see the problem on my Arm systems and IIRC Peter > said that he didn't face the problem on his x86 system. TIF_POLLING_NRFLAG doesn't seem to be defined on Arm. Peter said that he didn't see the problem, but perhaps that was just random. It requires a NUMA move to occur. I make 20 runs to be sure to see the problem at least once. But another machine might behave differently. I believe the call chain is: scheduler_tick trigger_load_balance nohz_balancer_kick kick_ilb smp_call_function_single_async generic_exec_single __smp_call_single_queue send_call_function_single_ipi call_function_single_prep_ipi set_nr_if_polling <====== sets need_resched I'll make a trace to reverify that. julia