From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2421F42AB7 for ; Mon, 1 Dec 2025 22:03:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764626583; cv=none; b=Ezbvjjm/YWtJyolxIxJCGbEcdDioeT0BWArUdXhdqSeMqIOJVsFplxNjL4ffROyr0C8xbwzPmU/SbM03Iipr+/m/x62rVQeTfFy2/8RKw/6nxakYAeipF9BqblJWXbGYLOIebm4N+chG7ve6L2URL/UhEOiUbpHQxnuD98T4QFY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764626583; c=relaxed/simple; bh=3nykJJwfpa04csSG2c36c7qT+xb5FDXycFNnHgJUV1A=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Tkp36ti9m3c23iZVap62Rh5V4c8tEgA2h2NoQ8hg7DK1i6fsXZbVFdK5Vu/Cg2fOyLredwXEKNPT35Jrun3chdnyFgAFahwHHOuKo+YkxxuYed1RxLWq7fwqzzDWWenXGuU82O4Gdr6PnHIAQjCiZIqvKJczR9XQXHYO6O1sa0k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Tca1JUOU; arc=none smtp.client-ip=209.85.221.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Tca1JUOU" Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-42b3c5defb2so3350136f8f.2 for ; Mon, 01 Dec 2025 14:03:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764626580; x=1765231380; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=Slf0k4+2vI7o7o2MkN0llBiVem5JXdk46tgvz0lUV6A=; b=Tca1JUOUoNF1hYrq5SNufm/Jz6B7CSFMbZbwmauurv7cAV3fEwlLtBggRRGJ5yHneN xiquKvftj+qAjbWFFz/cNZ2yAO5I8dmgcm+TKovUs3K+osmEmfwS2oL7/qZ3444fg0Ou mq9TIt1Fi9klevLI4sQg7Z8Xj4e6ouLpgokK1A9rIDqOKonO9YxdmPXNmDsTTO4Sp0SM 5fr6c1Hob+OeiJFwJgClfhZzeLgCVUw5zeC9jYyLyvA7dTHR44cr1M/B4GwsI1a/ekgn s02QPO7VeUrf4AYHvLxbyupCB2fvlBFuPolm8NKFkwm0WBTIIgP/UD8fyz1yxcTsKuBi Cf1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764626580; x=1765231380; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Slf0k4+2vI7o7o2MkN0llBiVem5JXdk46tgvz0lUV6A=; b=YKtNGVKon0Rc2+cKPJ/xTf5jFt9WYldqGfm7041YpG+WVB1yl5QaeAYqpZjRudN7Lh Nxny9WrbyLahtx9zHBlgmaceTr0blECApR08W0sxyo5hkUUyhsWbHPffZ0hldNR8DqKE +MQ8M0KuvLQYQUWv1qjmiokXHzANLtLhw5fPs0otM2btEZxMQvWuMztkzykbgVfSMtAN W8/EnelE/PlYGarTOHB4DuY8cVrt2eQ0C5xXRe4iTZhudHAJ3ygwD9wXmzTuvVO7upV3 LXkWY/K7BaPs7Posh9PRl/NMlycbQ1iBpe/uHnlMA+IVcm+CMTy9+u/NJ1SOvGCXlAR1 nZuA== X-Forwarded-Encrypted: i=1; AJvYcCU7Z6nQgC8iAN4ECpMIoj/VHirRj8pIZKCpxcObY/2n1X3SR5h5xipwaA6eSckgq2Apmi+FqSkydk3iXVo=@vger.kernel.org X-Gm-Message-State: AOJu0YzWI/D4/5u8t0vATFxMk/Z1hZ+CVVLDxlBeu4P81FXEIx2dMEk5 webviPFkhrfhaeBCvkhSlPyyudner615JtMv8cCniiuRFX1Mg1huJRoJ X-Gm-Gg: ASbGncse+teoV2CTyTsxPjjY/m2QUJ+zNWMNkiweGRrBfuyMOpUR2ciayDJ3XE7vB4n 803hLQj6Ln816DQWRaITiFj/55b0cxzEcU7gLdiK+nzgDIpX4AJuDxDorR0JIQYVwvzyzjeFHLZ kGX7PbluVI6uUc6dthiMQiLQ5R+kLWWmgsFc/PzRdVF4O7ZAEjYnsh6blW/4xtj5Epf4d164Rcn j5v1o+68MCWEHheac073lYias9sK6HGsFoEuFXJvIEUAtJe6kqIsii1Q2ujJQKtKmE13prfDqhy 71JclZm3nmF51+BGr4TLXcWnOS2kkeFV5NiWYTogrWMksqwDKEI+J2UJs8Q5CoaYBxE9XVdkHk9 inbeYwDQXnqK8EFE1/xM1xnWSHgYBp04u1YSJQGQR/yWq08oQSI0GQRSlGsLjL9LER0Kdxfcb4l 9X0MZU2IkqNTG3tGp683jcRtEuLuvBz8wIwLx8yzPqjflcHuhYnk28 X-Google-Smtp-Source: AGHT+IF30Jrk7/4lnzcxOisyn+L4uWp1ZDLg3kv6+o30EMZGZVSJ8FIKYlmfmm0rl9eME59WYyz4cw== X-Received: by 2002:a05:6000:2f88:b0:42b:3366:6330 with SMTP id ffacd0b85a97d-42cc1d22db5mr39067162f8f.57.1764626580287; Mon, 01 Dec 2025 14:03:00 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-42e1c5c30b8sm28883586f8f.7.2025.12.01.14.02.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Dec 2025 14:03:00 -0800 (PST) Date: Mon, 1 Dec 2025 22:02:58 +0000 From: David Laight To: Vincent Guittot Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, linux-kernel@vger.kernel.org, pierre.gondois@arm.com, kprateek.nayak@amd.com, qyousef@layalina.io, hongyan.xia2@arm.com, christian.loehle@arm.com, luis.machado@arm.com Subject: Re: [PATCH 0/6 v7] sched/fair: Add push task mecansim and hadle more EAS cases Message-ID: <20251201220258.651c7d08@pumpkin> In-Reply-To: <20251201091308.761711-1-vincent.guittot@linaro.org> References: <20251201091308.761711-1-vincent.guittot@linaro.org> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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 Content-Transfer-Encoding: 7bit On Mon, 1 Dec 2025 10:13:02 +0100 Vincent Guittot wrote: ... If you've got sched/fair.c out on the operating table have a look at all the code that multiplies by PELT_MIN_DIVISOR (about 48k). There are max_t(u32) that (I think) mask the product to 32bits (on 64bit) before assigning to a u64. Conversely on 32bit the product is only 32bits - even though it is assigned to a u64. There might a valid justification for the 'utilisation' fitting in 32bits, but I'm not sure it applies to any of the other fields. There are also all the 'long' variables in the code - which change size between 32bit and 64bit. I failed to spot an explanation as to why this is valid. I suspect they should all be either u32 or u64. This all means that variables the 'runnable_sum' may be truncated and much smaller than they ought to be. I think that means the scheduler can incorrectly think a 'session' is idle when, in fact, it is very busy. I didn't do a full analysis of the code, just looked at a few expressions. The 64bit code calculates 'long_var * PELT_MIN_DIVISOR' to get a 64bit product. Doing a full 64x64 multiply if 32bit is rather more expensive. Given PELT_MIN_DIVISOR is just a scale factor to get extra precision (I think the product decays with time) multiplying by 32768 would be much cheaper and have much the same effect. David