Received: by 2002:ab2:1149:0:b0:1f3:1f8c:d0c6 with SMTP id z9csp2713700lqz; Wed, 3 Apr 2024 06:40:13 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXSJgF+5vWVSF4COlwAz/doWu/1YBXeucnGTBJJfXvs8HRdj8tZ2dg0iw+iswactDkQfpGtzoZjhqgrmuND02a6LG5lzMiVBzmShtfTVA== X-Google-Smtp-Source: AGHT+IHNat+N3LoaQY0pV/MAM6lWwlyMBklIggaHoY1G3jZOA8mACapUPG7+MWnwKBRoqxpVUi/u X-Received: by 2002:a05:6830:1d41:b0:6e6:c9a5:6585 with SMTP id p1-20020a0568301d4100b006e6c9a56585mr17049552oth.23.1712151613096; Wed, 03 Apr 2024 06:40:13 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712151613; cv=pass; d=google.com; s=arc-20160816; b=t1bpftYugQ3dFkQKwJIn8PrIGiuPUm25+CebvvcVeVxrtpklIeo+s8XgSureXZ4Eue UKoSN/Q8NIqCkKHQdOSBecBkTP0+sszSQRw2JbCWtiyKQG9wvLUYcQo+tIwPcnxDVJov Re7CPzNdPE3MKzrr6lAy6bryM/q0so2VCpCH0Q/0Fq6PKlHK0mAwb3YTU+wS9Ms49DQD AcbURBMZaUIjz40tDZ7uGeqHGKeLB7UdweTLSGiiEuLinwuvWbK1XGsngR1IG+zAEgrw mOZZZJv3H6YlOTkWM66VM+QGzj6NdVMIf/gZtPmk5ikVYpWGmpo1e136yMKwIG+gNXXX MXAw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :subject:cc:to:from:date; bh=/Kz2gU1/d12UqiOgExp+vIbqrnrkbHVbdw6PK85IHow=; fh=AaLd1/8NvxW7Gknv5UuM/aLp1EnpqvJbBxCXOIUjtKw=; b=NabPz+Pj66KvneyApxSN7d7M119t1L2e6GvN8uSOAGL7otnw6/fqT8cxsnc4uN4HdB qoRMaOVHJMAtyzAo6MYrEnrxTmwd7h+5UM3mQAtIzcm0ZwfAHMYmCiz3awexQ/vLVk7h KD+M6wQ4ZwNmrNVtp9ez6ecyyO2n6eS7trIZEzsrehbOTyG5JSSyf51ya4i2Al+Gq+Nm FaoYsLMfvYPEca+mvEFbtEZ2nceRcu6sNeiLgGBP/JWd8ClU/cBx424x0rP/TIP4PSPX DGFAW3ZVcesJEr6E/dAWjZv4RbRBFdREClaSSHS5f4Vztd3V/btTd808EV83y+hJSPAN vFGQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-129857-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-129857-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id df7-20020a056214080700b006991b67d51esi3421483qvb.277.2024.04.03.06.40.12 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 06:40:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-129857-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-129857-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-129857-linux.lists.archive=gmail.com@vger.kernel.org" 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 C9DB21C25AF4 for ; Wed, 3 Apr 2024 13:40:12 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 01B411487C4; Wed, 3 Apr 2024 13:40:07 +0000 (UTC) Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 80060145B36 for ; Wed, 3 Apr 2024 13:40:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712151606; cv=none; b=nE7o6VPX6zIAFcdvtpfqMOjf6CzG41iv1VaduKMV8n9anUx3TQFDCglAuWDM2LRXnVUjui9YFlDPGzyOQvK2a2h0Jd4eKQMjfJ5SRanM3lizWFyvR6aiv0GTVKh37NQy9fkm8l7QOeTGNiRRfHFC2iYfCy+TZ+QrmsQGBuoffYw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712151606; c=relaxed/simple; bh=rZ8RKwrxusezQ6XtZmnAt0t/LoLT/TISBYJDEc/S8WY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FF8AWqZ+8fbJ6I30m2ok9AOhQ2GWXczqGm/ES+pQ9F7tvklSfz+yvqsIFYDYfS586yHFGSWe1bqZlb4FibvuV7hSz+IgNZlZ6IpzvORcjrU5tlmMwRm6NMw7+wO5sJbUP3SOSJwbZVsIi6+AgSesP2M8ILrLtqKgN7jJmUx9Bv0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D8DCC43390; Wed, 3 Apr 2024 13:40:04 +0000 (UTC) Date: Wed, 3 Apr 2024 09:42:24 -0400 From: Steven Rostedt To: Vincent Guittot Cc: Qais Yousef , Ingo Molnar , Peter Zijlstra , Juri Lelli , Daniel Bristot de Oliveira , Thomas Gleixner , "Paul E. McKenney" , Joel Fernandes , John Stultz , Dietmar Eggemann , linux-kernel@vger.kernel.org, Yabin Cui Subject: Re: [PATCH] sched/pi: Reweight fair_policy() tasks when inheriting prio Message-ID: <20240403094224.105fdef0@gandalf.local.home> In-Reply-To: References: <20240403005930.1587032-1-qyousef@layalina.io> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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 Wed, 3 Apr 2024 15:11:06 +0200 Vincent Guittot wrote: > On Wed, 3 Apr 2024 at 02:59, Qais Yousef wrote: > > > > For fair tasks inheriting the priority (nice) without reweighting is > > a NOP as the task's share won't change. > > AFAICT, there is no nice priority inheritance with rt_mutex; All nice > tasks are sorted with the same "default prio" in the rb waiter tree. > This means that the rt top waiter is not the cfs with highest prio but > the 1st cfs waiting for the mutex. I think the issue here is that the running process doesn't update its weight and if there are other tasks that are not contending on this mutex, they can still starve the lock owner. IIUC (it's been ages since I looked at the code), high nice values (low priority) turn to at lease nice 0 when they are "boosted". It doesn't improve their chances of getting the lock though. > > > > > This is visible when running with PTHREAD_PRIO_INHERIT where fair tasks > > with low priority values are susceptible to starvation leading to PI > > like impact on lock contention. > > > > The logic in rt_mutex will reset these low priority fair tasks into nice > > 0, but without the additional reweight operation to actually update the > > weights, it doesn't have the desired impact of boosting them to allow > > them to run sooner/longer to release the lock. > > > > Apply the reweight for fair_policy() tasks to achieve the desired boost > > for those low nice values tasks. Note that boost here means resetting > > their nice to 0; as this is what the current logic does for fair tasks. > > But you can at the opposite decrease the cfs prio of a task > and even worse with the comment : > /* XXX used to be waiter->prio, not waiter->task->prio */ > > we use the prio of the top cfs waiter (ie the one waiting for the > lock) not the default 0 so it can be anything in the range [-20:19] > > Then, a task with low prio (i.e. nice > 0) can get a prio boost even > if this task and the waiter are low priority tasks Yeah, I'm all confused to exactly how the inheritance works with SCHED_OTHER. I know John Stultz worked on this for a bit recently. He's Cc'ed. But may not be paying attention ;-) -- Steve