Received: by 2002:a05:7412:2a91:b0:fc:a2b0:25d7 with SMTP id u17csp600248rdh; Wed, 14 Feb 2024 06:23:49 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCU6R7n/hELkve2WOhkSxgJn8AQLT+VzYsFzLdbNWfmU+Jn4BhW9zKSpiglO1c90TTtwnu0t1aMlMNjxbe3HUnl5juzaPEYy45u2dzdFYg== X-Google-Smtp-Source: AGHT+IEtiO8g/cwVOMg6DeGsQaCCf7jx4vLdstp/vBIsjMCjGEgdafMNmjKLEKDOEWzwIc3OZOOk X-Received: by 2002:a05:6a00:2b47:b0:6e0:4608:5ed5 with SMTP id du7-20020a056a002b4700b006e046085ed5mr2462777pfb.17.1707920629246; Wed, 14 Feb 2024 06:23:49 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707920629; cv=pass; d=google.com; s=arc-20160816; b=z/Knj8Im7dF9/DlmFLVSzJCSpWcy1gGGUBYTvUcLAUU3eTNs0xCxQMX9EQ7SrfKaBd aQyRCMDbORei8tQ8zLnJUoZIX7Nu2puSz6KId8BoKCoOXQ48HLgj3NhG5AFVDOhthPwZ i/2Yj9VNNG7ij/FQxMjpaVtXxJOPin6S2RGEdQVDHEN0beFxOJsnOi1slEAGdyc6KBm3 U90GxENhCoALuwIYX1nab8G1n6wQk9w9eT72//Grjs6pX3kOtZPQXuwZo5oRfkVweCQ2 vruAzKjBYTFSMP0WacH9wGionkiEvRZsCR32LsZUgObX665vGgVQN1PEhXhkrjxBqal+ 4sag== 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:dkim-signature; bh=lhWFN3kqXDIHiZ2BHSLySgOvggBFSS7rMeVom9i5kkU=; fh=LtP6BZ8s5VTCYBOY4xN1nIVx2Uyshqen2WSDFhqZQ+g=; b=cxz7obXXiBOEbIPKi0QZP+kLQyNZmPaZm159qw48hcYvGYbCP9QznW+fkNKdy/+ohR Xbak30EcSgj9UDVlq1mwa8OLL0b0poHlY2dHxeOtTOup1+pn3+I+7QHahKkOSXNwTbvs qSLlg9MuqjUYFr/1aPoqqzGGES8PIV+teu3FAaPp+ycT6Gj9sqHOkjy+b+Vji3HAACpc EDU1Fby8fpnKJ+u1/oTEEzihffb2QAy23dvPPMjZN5KYt+Q8wH16EPtvhKbTQ+CH1Wft 7ot7WicwpGdI0uzuRmigqil0m2IGP5C9oFafZPf6+z01DZL16IWVeJsFgMc86N15iZ79 yLIA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SLdWMLLh; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-65332-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-65332-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org X-Forwarded-Encrypted: i=2; AJvYcCX9CKy+iKp2dRvASsx9gZtVvnCUovx5diLdz9/TFLZFr3Ugu7opw0njJThNrqNIMGwcdnt/rNus7aONs1OqybfRPRquctkqd5z2mTOWxg== Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id m9-20020aa78a09000000b006ddc80e5366si8307632pfa.86.2024.02.14.06.23.49 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Feb 2024 06:23:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-65332-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SLdWMLLh; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-65332-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-65332-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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 sv.mirrors.kernel.org (Postfix) with ESMTPS id E42C8280E54 for ; Wed, 14 Feb 2024 14:23:48 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A08F855E45; Wed, 14 Feb 2024 14:23:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SLdWMLLh" 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 BDE0C55C0B for ; Wed, 14 Feb 2024 14:23:41 +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=1707920621; cv=none; b=ri5dZP238w+7N30kr+oT89lH/qBPq1SkOb9OowE8h+n0grDL1IOt69k7blI18XQ1fHalrLRddAfvswBuqHBTlW4X1aIbg+9a9hvYPx4bMrGX7TJXO5LWTefL0AogBXXAqmtqmp2Ik35aLJq0QydQMqMtZACBJTO/t/iuZnVWbv8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707920621; c=relaxed/simple; bh=QUtqKoQM0XD8W0yp0rYh69IGkcbpWjeYiG8tLSkhjPI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=m6apS2Hx0bPP908N9FLU8SJhOtqTY44/6dn5xnNCZyblrpXEIwskhh0SbvSvNQXizx44jh3RA9N81L4nU030wdhoHNUste1y9tmN+IS5BVSoPv6xYWxHfjt3VyowIkbTVFG3AuVB68rcyblpDr26a39Y79Lhhv1IH7xDUN/onCM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SLdWMLLh; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 95AB6C433C7; Wed, 14 Feb 2024 14:23:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1707920621; bh=QUtqKoQM0XD8W0yp0rYh69IGkcbpWjeYiG8tLSkhjPI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=SLdWMLLh+fxJfGn8rbVS5zwCXNZZrqrY3tVJ9WeOApJEMr1OqcHLYlntMCv42pnQf IwPC5n9eMZpiZm4VIjJcxaZ96shecDzSiBGPmTYFrGZJAjWDexTaNvWxC/TBc43IhK IHc392VKdPuehVA/Rdc0QkLoqww9/V4SNdo5cvYgLV0ykn/7T3DxwFILyfzbBztb8g NonMDuDHOu8Ed6rf8v76jHwsnaq2UTdEMl640rk7c+YkTdyzjIjoR0v6c21ncKne02 QeNky69MyOFL5ZxhirvsxNIl1cIF0ht3VLx4/PepJPwCX5OJoQT84u5lGiarWHx+ux +Cvhxd7jEPBBw== Message-ID: <091ca2ea-202d-4685-92ea-529186a94f0a@kernel.org> Date: Wed, 14 Feb 2024 15:23:35 +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 v5 7/7] sched/fair: Fair server interface Content-Language: en-US, pt-BR, it-IT To: Joel Fernandes , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot Cc: Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Valentin Schneider , linux-kernel@vger.kernel.org, Luca Abeni , Tommaso Cucinotta , Thomas Gleixner , Vineeth Pillai , Shuah Khan , Phil Auld References: <26adad2378c8b15533e4f6216c2863341e587f57.1699095159.git.bristot@kernel.org> <8cbf4bcd-431b-466f-b62d-ee03932e97f5@joelfernandes.org> From: Daniel Bristot de Oliveira In-Reply-To: <8cbf4bcd-431b-466f-b62d-ee03932e97f5@joelfernandes.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2/13/24 03:13, Joel Fernandes wrote: > > > On 11/4/2023 6:59 AM, Daniel Bristot de Oliveira wrote: >> Add an interface for fair server setup on debugfs. >> >> Each rq have three files under /sys/kernel/debug/sched/rq/CPU{ID}: >> >> - fair_server_runtime: set runtime in ns >> - fair_server_period: set period in ns >> - fair_server_defer: on/off for the defer mechanism > > Btw Daniel, there is an interesting side-effect of this interface having runtime > and period in 2 separate files :) > > Say I want to set a CPU to 5ms / 10ms. > > I cannot set either period or runtime to 5ms or 10ms directly. > > I have to first set period to 100ms, then set runtime to 50ms, then set period > to 50ms, then set runtime to 5ms, then finally set period to 10ms. Hummm yeah I could reproduce that, it seems that it is not even a problem of having two files, but a bug in the logic, I will have a look. > The reason seems to be because otherwise runtime / period will not be > accomodated and will cause dl_overflow issues. > > I'd suggest providing both runtime and period in the same interface to make it > more easier to use. However, for the testing I am going with what we have. > > Also a request: > > I was wondering if a new version of the last 3 patches could be posted to > LKML or shared in a tree somewhere. I am trying to sync to mainline and > rebase our latest fixes on top of that, however it is difficult to do because > these 3 patches are in bit of a flux (example the discussion between you and > Peter about update_curr()). What's the best way to move forward with rebasing > our fix contributions? Juri and I chat about, and we think it is a good thing to re-send this patch set, including a fix I have to it (to avoid regression wrt rt throttling), explaining these things in the mailing list so peter will be able to follow the discussion. I still need to finish testing, and to make a proper cover page with all updates, the latest thing is here (tm): https://git.kernel.org/pub/scm/linux/kernel/git/bristot/linux.git/log/?h=dl_server_v6 It is based on peter's sched/more. I will probably re-send it today or tomorrow, but at least you can have a look at it. Another reason to send it is to get the regression test machinery running.... I am going with the sched/more in Peter's queue.git > unless you/Peter prefer something else. And I added your update_curr() > suggestion onto that, let me know if you disagree with it: > > @@ -1173,6 +1171,8 @@ static void update_curr(struct cfs_rq *cfs_rq) > > if (entity_is_task(curr)) > update_curr_task(task_of(curr), delta_exec); > + else > + dl_server_update(&rq_of(cfs_rq)->fair_server, delta_exec); > > account_cfs_rq_runtime(cfs_rq, delta_exec); > } That part of the code was optimized by peter during the last round of discussions. It is like this now: ------------ %< ----------- - if (entity_is_task(curr)) - update_curr_task(task_of(curr), delta_exec); + if (entity_is_task(curr)) { + struct task_struct *p = task_of(curr); + update_curr_task(p, delta_exec); + /* + * Any fair task that runs outside of fair_server should + * account against fair_server such that it can account for + * this time and possibly avoid running this period. + */ + if (p->dl_server != &rq->fair_server) + dl_server_update(&rq->fair_server, delta_exec); + } ------------ >% ----------- It is not straightforward to understand... but the ideia is: if it is a task, and the server is ! of the fair server, discount time directly from the fair server. This also means that if dl_server is NULL (the server is not enabled) it will discount time from the fair server. -- Daniel > thanks, > > - Joel