From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) (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 9D6922F6911 for ; Tue, 10 Mar 2026 15:11:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773155485; cv=none; b=lDEZq9QTzn6OErWPRdkMtmRmV2YnrxX6UHAqzSFvgMnL1R9/a6uF8k2sHjCH8KM/lEWk+xG/rVpGOD/Mws97x74er1pMteowIsY7ATF3eK+aydfa/8moq+XI1nkDhs50WUsUZeqikISqp+96oSF3ZHfZ1RYkSD7bL5v8HWlLcfw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773155485; c=relaxed/simple; bh=/bO2tZ2WFBY8fGiVclxmRVqpUNZ579jvBX1F8zA3iZk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oXUqNh1tTJorSyK2cO9dLELjo8U7vQRBDzP1rCsOQI04tDda8ubDsiW+F+VRmq5aKLPaiRvkB7PdTRcDOxT0WUOihIhQWT++kpCUqKMitYjhUW8wR2pYzgb2n1CqwM1ClUuo61DYEF3i7g38WYczsSRqKTIZVL7Cudyy/Kgb7o0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=layalina.io; spf=pass smtp.mailfrom=layalina.io; dkim=pass (2048-bit key) header.d=layalina-io.20230601.gappssmtp.com header.i=@layalina-io.20230601.gappssmtp.com header.b=sxxHksGf; arc=none smtp.client-ip=209.85.208.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=layalina.io Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=layalina.io Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=layalina-io.20230601.gappssmtp.com header.i=@layalina-io.20230601.gappssmtp.com header.b="sxxHksGf" Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-662dc987dfdso1101296a12.1 for ; Tue, 10 Mar 2026 08:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=layalina-io.20230601.gappssmtp.com; s=20230601; t=1773155482; x=1773760282; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=aHli7fAqmOjlUG7gEv3k+G7Fg9U3Jx0yjklsIKBeztc=; b=sxxHksGfex+tfvEV5fPvm1BqF7PQ9e50N6XMuncLVZLND0ZQ0+kU+x53F5P44tKNkQ QBtNVuTfQazxU147H2/Apm5e7rDI+YT5GPTikR5XZ03XxbLim1L0lEhISiofhmNhpJ4o 8yq6dFUyUX0a/dEsELfYGf2M6yQi4OJ+LxZ+UcmzsS+M2MNuZfyKZdBp1YGY51U/fPme dPdDqyAzAaCOQZv2m/UvJFPCwU7Ls+M2OnD6zqTpU33BZRMNM+bNGcx9X8wQcYe/5WN1 iepGrFDwoxgyELIc7klh0uIh6b8/r+cCp1h30FHnHtxA8Xwk51cidKHOsUEcqYoUy4EY V6eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773155482; x=1773760282; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aHli7fAqmOjlUG7gEv3k+G7Fg9U3Jx0yjklsIKBeztc=; b=C1TZpgJ76UO7hHPVF/LBJLXjqbS5jfqdwqP2gXxRIJxG+34fQz9AZ0DRkty33RLFBx eBbxrF8ILb0f7hur9Vni0ZVqRjvefiK+ec3jS+12KgC+Vc7XHolSr3/onk9Fqv3HXZdb 6lGSC9KmQFnZG/KyKw4wD7wOm0ozJF+oAO8WwJ1FKKOzlcAH8MWQ8n1ksbQaxhS4jP5f umHUbfnzepHPs/oABgpwiibtgpgQCFQnIUaoksYdcQ47M3rnSt5ExVAWQeIJdFPluiPT 8jAJneUCvc/osioz712GItIAP9zqAKWk5c7qRs1RIGUshf47SuMVt+//DiddNOZwsx7W FyGw== X-Forwarded-Encrypted: i=1; AJvYcCWhNmbsYe8aN+qlNtPVUEYhMaI8MtFWRMva6iZWUsV2Ej/cxPfd+FpqzxoO2DMc35JI4c4q5jPhueXzKQ4=@vger.kernel.org X-Gm-Message-State: AOJu0YwScshZnpr2CB8AFbtXoet2Xf4AA33P8nBMuFHOM1YArclT5Znx tFBjsxIiISo/wMhOrC0Sy6Lip094bjMYjYts6TBDW07JSSgPCWZhjdjAT1cQfdkRvWQ= X-Gm-Gg: ATEYQzz8Ge6lnOJW+reDc9SBMSh4roRjLIAAru9OcTM5Dc8trxxOoxipR4NFPKODZY9 AihONUIn29fHx5hoYEQE9AAiiEb4XHca0uRJ+VtAbiQ6o4PYohk9Goz4vbsSq2aDaVhvN47MTtP TMZh+PktR9BiGIJ7BxzZF7AUT3unkCMBPDDRKZyKU31LnTvu2aCIuXaRoeKnxgrHc55dcy8hjKm IWp0CPCf4fXGFR8arOtTHYYRCmcsVN7a05GWrqE10v2cnOIX2omUFLsBqTxFG8n//tTDJgqRcVw ZXBtL0DzZ65AnPE5T00b6XAKsWXsVHZRD1UuQWkpojZwGBqBaqAYHKANXmn/gyRiiGQD/UkpD4J bHdsWkArjiy/Dk9SHUyQZwi7HlDDR4kO2S5/6LgzSdEuVZfKvyZ8VFH8kT4pnkA+BEvgA1laKt5 EBHYZBL88jrQIcZPVyc5a+35Z84KE= X-Received: by 2002:a05:6402:278d:b0:659:4295:96e with SMTP id 4fb4d7f45d1cf-6619d45c877mr7555495a12.1.1773155481827; Tue, 10 Mar 2026 08:11:21 -0700 (PDT) Received: from airbuntu ([146.70.179.26]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-661a55a660csm4286270a12.33.2026.03.10.08.11.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 08:11:21 -0700 (PDT) Date: Tue, 10 Mar 2026 15:11:16 +0000 From: Qais Yousef To: Pierre Gondois Cc: Vincent Guittot , 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, kprateek.nayak@amd.com, christian.loehle@arm.com Subject: Re: [PATCH 0/6 v8] sched/fair: Add push task mechanism and handle more EAS cases Message-ID: <20260310151116.4n3j4cpxlgcfew4k@airbuntu> References: <20251202181242.1536213-1-vincent.guittot@linaro.org> <520385b2-545a-4ac7-ae05-06d24845f512@arm.com> <20260310041638.imaqwuaau2hunxby@airbuntu> <84da9a4c-8637-4303-91c4-cfd3b558ab8c@arm.com> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <84da9a4c-8637-4303-91c4-cfd3b558ab8c@arm.com> On 03/10/26 11:27, Pierre Gondois wrote: > If we have 2 little CPUs (CPU0/CPU1) with 4 tasks: > - TaskA: Nice=10 (i.e. weight=110) > - Task[B,C,D]: Nice=15 (i.e. weight=36) > > Then using nr_running would yield a placement as with 2 tasks > on each CPU: > - CPU0: TaskA + TaskB >   Total weight = 110 + 36 = 146 > - CPU1: TaskC + TaskD >   Total weight = 36 + 36 = 52 > With such placement: > - TaskA and TaskB are receiving less throughput > - TaskC and TaskD are receiving more throughput > than what they would if the placement was balanced. > > This is not compliant with the scheduler Nice interface. This is over thinking it. On 2 core SMP system, no uclamp and no EAS. 4 always busy tasks with different nice values will still be placed based on load and neither wake up path nor load balancer has notion of throughput based on nice to manage task placement. Generally with EEVDF managing the slice size is better than nice value and with the QoS framework we are proposing I think nice value is better locked down to 0. But we shall see. More over the idea is to enable wake up path to be multi-modal and coherent with lb decision (via push lb). So fixing all these problems is possible in the future, fingers crossed without much added complexity. But again, we shall see.