From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 10244207A2B for ; Thu, 13 Feb 2025 06:20:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739427654; cv=none; b=YNLVsMHr7XeUcjuGizzOQEFgRpVExvjqS2thM+yMU+N8XHwdmS6XyDxUIP3/s64QpnPpfMo3v1VWGC7WuttbANrL6G2ipnPEtCDt+KLOBsFqbIpibfZHASE0TQfBgpgj4lMH/lqcJg4eYdboDzVzIGNTXT5lc8QgRYi54k8ZhI0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739427654; c=relaxed/simple; bh=ujajjJF3gxYdA1DcNCIqKS9o38/7j0hv1rZ6wwtwKUY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MQ36R7gpm+pJCzIClDnoIet0JXFy3KEpUYMrpifwUUaeChH2kHHF+Ly8HTyQ59c5IaffxAx+bDJAwYJ1uI/GvBeAR/7o2U+aL6xpsQFkV5ffl/SfhOwV8RYEeiSiIunusldr0RO+eZ11rsoqk585AMVcBqUujFa6RYX70il8HlA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=IEBT+tLn; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="IEBT+tLn" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1739427652; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CPPPQaWJNVckUPtigjDkhfhBpenPmQjuRXN55oSVE/w=; b=IEBT+tLna3d2EfConaaQ8i333mdwmcx9lqsksyFEdKuVOOX3RARiNF3nVCdzM2/i04psPi JcsPcRJNv17XPBOwHz9aE0BjgxzA45pdj3oJuInhuO/EQeWpd/mQ02lX8lQ0FaUbe29BVh /uUbvkMDDwI5iCGDMKPs1iGuHu/j+cg= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-637-MpgHEaHSOdu4UqgNv41SGQ-1; Thu, 13 Feb 2025 01:20:50 -0500 X-MC-Unique: MpgHEaHSOdu4UqgNv41SGQ-1 X-Mimecast-MFC-AGG-ID: MpgHEaHSOdu4UqgNv41SGQ Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-4395ff90167so2237675e9.2 for ; Wed, 12 Feb 2025 22:20:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739427649; x=1740032449; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=CPPPQaWJNVckUPtigjDkhfhBpenPmQjuRXN55oSVE/w=; b=G/it1UJYoAEb7o1pZqswEovhbzN+TtpBz5d1057G1TmxLrjyVy1jpfbSq/URcsxEi0 5VmucNTApkOQOGPnZzcdj9GN0xgzOZ0nDsgVq0kQPtsWsYLcl5oOL4M1cE/NIz3kBr43 q5Boyu6mcYE2AAXhQ4usvftWQvmkK5iy1kAZN+7TDGISegVp6CXmzzZBkSaR7xAMb1ya N8yNOiUjjGnPb6QZDIW+sNhhg/tegaoGzuogMIMmO+hWDTpZ3BL8pxmpmzgLBWTDpq5B KxWhbbqcFljW7eAp/QppMUYRbEqFtSa1fsrr3oOGY/z+CBJYbbolG4UpivjLbIzbFICh NO9A== X-Forwarded-Encrypted: i=1; AJvYcCWuFZEkjK/az8+yxYyTvVSbC1IIFW9f7Z2/KCC2LeUKbelw7nMKI7H5I90IiX3/3HvZYp2S64Tz6BUj6Os=@vger.kernel.org X-Gm-Message-State: AOJu0YxNBNu65gaIpHw5+9+AHExpwWMUDu7DI6O4eqyQ1EyieDpH3C9M sbnAit/bRJ7aE2PgUcKFNS3qPQ/gC+wq+wLchGPKchiGPkl6HK1/5AIW0MWeeToYIqICQJVItp+ tXw56CUe5TKDfWnhfGq5+JYA9FQ17hiucmff/7PpN9LjbeDIYfWSYj2hu1ovZNQ== X-Gm-Gg: ASbGncskHV7aDRfaEs24e7M0QyrPBB55YBwrFkbGjVxFbWtIhtmhSe25ebEXjUXFhBc y7XbiDPZQ44mdD+vTlQmWukB6X0+2zFsZ768qaw3QoX+62DBFCvJltPa3S2IcZfdEwEiXj9GRcU 3RnXNTstfP6WTRUiYkuAFiWZObELupSYrUhslffAiBLSp9RWF2Z/DWme/gzDj9jpLlkKW0T5PX2 whWi3GffnNUgevgc/n/zm1lVj5UhTiHEcE7xoCXDB1X3VqzkgZEe0bNb++6b7ti9D9oRwehGVPS FYEuuLtdv5e+cnbm1MOBMOX+9He1iABRhQ== X-Received: by 2002:a05:600c:34cf:b0:431:3bf9:3ebb with SMTP id 5b1f17b1804b1-439581b2618mr55155145e9.24.1739427649050; Wed, 12 Feb 2025 22:20:49 -0800 (PST) X-Google-Smtp-Source: AGHT+IER6/42+eVDeZwjdE+jxN4B0+qhxJwM/n+zSdf4mIKkK9A70FFseUlVSNAfLLV/nC108HkX3g== X-Received: by 2002:a05:600c:34cf:b0:431:3bf9:3ebb with SMTP id 5b1f17b1804b1-439581b2618mr55154855e9.24.1739427648614; Wed, 12 Feb 2025 22:20:48 -0800 (PST) Received: from jlelli-thinkpadt14gen4.remote.csb ([151.29.34.42]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4395a1aa779sm38582615e9.30.2025.02.12.22.20.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Feb 2025 22:20:48 -0800 (PST) Date: Thu, 13 Feb 2025 07:20:45 +0100 From: Juri Lelli To: Dietmar Eggemann Cc: Christian Loehle , Jon Hunter , Thierry Reding , Waiman Long , Tejun Heo , Johannes Weiner , Michal Koutny , Ingo Molnar , Peter Zijlstra , Vincent Guittot , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Phil Auld , Qais Yousef , Sebastian Andrzej Siewior , "Joel Fernandes (Google)" , Suleiman Souhlal , Aashish Sharma , Shin Kawamura , Vineeth Remanan Pillai , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, "linux-tegra@vger.kernel.org" Subject: Re: [PATCH v2 3/2] sched/deadline: Check bandwidth overflow earlier for hotplug Message-ID: References: <8572b3bc-46ec-4180-ba55-aa6b9ab7502b@nvidia.com> <5a36a2e8-bd78-4875-9b9e-814468ca6692@arm.com> <8ff19556-a656-4f11-a10c-6f9b92ec9cea@arm.com> <285a43db-c36d-400e-8041-0566f089a482@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=us-ascii Content-Disposition: inline In-Reply-To: <285a43db-c36d-400e-8041-0566f089a482@arm.com> On 12/02/25 19:22, Dietmar Eggemann wrote: > On 11/02/2025 11:42, Juri Lelli wrote: ... > > What about we actually ignore them consistently? We already do that for > > admission control, so maybe we can do that when rebuilding domains as > > well (until we find maybe a better way to deal with them). > > > > Does the following make any difference? > > It at least seems to solve the issue. And like you mentioned on irc, we > don't know the bw req of sugov anyway. > > So with this change we start with 'dl_bw->total_bw = 0' even w/ sugov tasks. > > dl_rq[0]: > .dl_nr_running : 0 > .dl_bw->bw : 996147 > .dl_bw->total_bw : 0 <-- ! > > IMHO, people who want to run serious DL can always check whether there > are already these infrastructural DL tasks or even avoid schedutil. It definitely not ideal and admittedly gross, but not worse than what we are doing already considering we ignore sugovs at AC and the current bandwidth allocation its there only to help with PI. So, duck tape. :/ A more proper way to work with this would entail coming up with sensible bandwidth allocation for sugovs, but that's most probably hardware specific, so I am not sure how we can make that general enough. Anyway, looks like Jon was still seeing the issue. I asked him to verify he is using all the proposed changes. Let's see what he reports. Best, Juri