Received: by 2002:a05:7412:bbc7:b0:fc:a2b0:25d7 with SMTP id kh7csp3179836rdb; Tue, 6 Feb 2024 09:17:40 -0800 (PST) X-Google-Smtp-Source: AGHT+IGCGVDwdfwj08TvD7EJ0SH9IHiaGWanw2bP53F1sxFQwy07UaIh7urrkYUv42WYpoveX5+l X-Received: by 2002:a05:6808:1882:b0:3bf:e549:d38e with SMTP id bi2-20020a056808188200b003bfe549d38emr2011240oib.46.1707239860248; Tue, 06 Feb 2024 09:17:40 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707239860; cv=pass; d=google.com; s=arc-20160816; b=g542/IB82+ns4YklFwEQ9QE8iqYIJMuhZcUOnIEsnllJEI51JskL2970Srb6TruBgY BsPK8YobzPM1Oq3H8S/P21b3GSz1PUiqvIIZXFJK5yzlaujF91544xmqCYdGOLiIeLSg AZui8YB4HvNjsFftk4neCau30nhv+qoZWvi3KrOkpSBvHlIqyAS6V6xFnp4YH73wwxp3 Rwqn6ZQPsbBHIu3aAPYXYmrIFB0vCoMU0urXWCD/vYfRAXSV+sioywXhAI5w5Gpbx/V3 pBp5hVh4RSG2TbmYToJE8kq6PW0+JlMnBwwHBThzYGvSkTRJDQ8rMe4NK7kryCkArl/t msow== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=kLNspAi3BvjiFuuuWWQdYGqAd8gNLp5mq6H2Jf6NyeY=; fh=AOZ0NprWfw6UwkDvjQ3lhAx1V1gcg55nZuVS/ogVx5M=; b=tWY0knWrN20GaSMYFTa1YRHYiiHPU1iDEap98pKmrt0vvhtUr1XnZxFy6B+D/FLJoF 2QjpjI03ZcDwwbyjME6WSluOaIvcszgMEm7LGRY7at0pGk5+Uurxft+iIfdOTyWigQa2 Fp0Meb70HSrGHWVxk5noFM4BJSuqgVdsgE3qr3kU4BkGznWbcB2E6Cz1yYS4z8qiU87a ke70qHd6XaTDqgAIbwF4n8GIaLbJI/4ugetAGLl2BTJIT0DFqoLmrnTv+d/2SacYJSl0 j2IrrqhS+XUI8PXCnh2TX+p9v68ZYlLx3WgAZutJAIzdPGQiuJPLlUaLPCzvA7JZYBgn /Tgw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-55360-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-55360-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com X-Forwarded-Encrypted: i=1; AJvYcCUBzLsKJKWXsQhDuWAjhWAnxeQmqnPp4cie4g2bW3PgS/BH+E1v577MGtL8ijABQ4di9WujSPG80Ts2YQWNbafl9DV+uNeR8m6xKxOZTg== Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id y22-20020ab05616000000b007cec9571054si422069uaa.36.2024.02.06.09.17.40 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Feb 2024 09:17:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-55360-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-55360-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-55360-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com 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 ny.mirrors.kernel.org (Postfix) with ESMTPS id F06591C2244F for ; Tue, 6 Feb 2024 17:17:39 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 726C1D52F; Tue, 6 Feb 2024 17:17:29 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 12093D51A for ; Tue, 6 Feb 2024 17:17:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707239849; cv=none; b=nzjCGdxyR12t9rLDKgrU7E9XhM7WlYnpMgCM3+f2E2hwPFWi5A5B2ogj7smTVf8K8Rr9Apru/H/GEgRAEfzYIsZxizZSBLXHMLrGlrofX0HV51FVIO7D8IzZxTksi4USNzqHFCZWe5y7xb+/b2THzpz6ZlIax071Zly6SThX1/Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707239849; c=relaxed/simple; bh=cfHGigLto/qWdnBkKMG62iRBESRbiwnB/3N57/mdW90=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=B12YSNFC4QF3Co+ni2KN29tuQDQNj8bSb35lwH59UEdeY4kugoVGJlMs+nXYEVgd9ojB6n87Yt38z1BongAXLbPh1qBhcDxs0MpTGRpogZRiP2T6qaGpkcpE0bxAAsA4gaNgtAwMiJyETLS84kStRx34+LKPeMe0w1plE6wqlRM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 58FFA1FB; Tue, 6 Feb 2024 09:18:07 -0800 (PST) Received: from [192.168.178.6] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E8AE13F64C; Tue, 6 Feb 2024 09:17:23 -0800 (PST) Message-ID: Date: Tue, 6 Feb 2024 18:17:22 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/2] sched/fair: Check a task has a fitting cpu when updating misfit Content-Language: en-US To: Qais Yousef Cc: Vincent Guittot , Ingo Molnar , Peter Zijlstra , linux-kernel@vger.kernel.org, Pierre Gondois References: <20240105222014.1025040-1-qyousef@layalina.io> <20240105222014.1025040-2-qyousef@layalina.io> <20240124222959.ikwnbxkcjaxuiqp2@airbuntu> <20240126014602.wdcro3ajffpna4fp@airbuntu> <5249d534-d7ac-4cbc-a696-f269cb61c7d1@arm.com> <20240206150653.34ouqhbt4yz2cmgo@airbuntu> From: Dietmar Eggemann In-Reply-To: <20240206150653.34ouqhbt4yz2cmgo@airbuntu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06/02/2024 16:06, Qais Yousef wrote: > On 02/05/24 20:49, Dietmar Eggemann wrote: >> On 26/01/2024 02:46, Qais Yousef wrote: >>> On 01/25/24 18:40, Vincent Guittot wrote: >>>> On Wed, 24 Jan 2024 at 23:30, Qais Yousef wrote: >>>>> >>>>> On 01/23/24 09:26, Vincent Guittot wrote: >>>>>> On Fri, 5 Jan 2024 at 23:20, Qais Yousef wrote: >>>>>>> >>>>>>> From: Qais Yousef [...] >>> It seems we flatten topologies but not sched domains. I see all cpus shown as >>> core_siblings. The DT for apple silicon sets clusters in the cpu-map - which >>> seems the flatten topology stuff detect LLC correctly but still keeps the >>> sched-domains not flattened. Is this a bug? I thought we will end up with one >>> sched domain still. >> >> IMHO, if you have a cpu_map entry with > 1 cluster in your dtb, you end >> up with MC and PKG (former DIE) Sched Domain (SD) level. And misfit load > > Hmm, okay. I thought the detection of topology where we know the LLC is shared > will cause the sched domains to collapse too. > >> balance takes potentially longer on PKG than to MC. > > Why potentially longer? We iterate through the domains the CPU belong to. If > the first iteration (at MC) pulled something, then once we go to PKG then we're > less likely to pull again? There are a couple of mechanisms in place to let load-balance on higher sd levels happen less frequently, eg: load_balance() -> should_we_balance() + continue_balancing interval = get_sd_balance_interval(sd, busy) in rebalance_domains() rq->avg_idle versus sd->max_newidle_lb_cost > Anyway. I think I am hitting a bug here. The behavior doesn't look right to me > given the delays I'm seeing and the fact we do the ilb but for some reason fail > to pull [...]