mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bagas Sanjaya <bagasdotme@gmail.com>
To: Vineeth Pillai <vineeth@bitbyteword.org>,
	luca.abeni@santannapisa.it, Juri Lelli <juri.lelli@redhat.com>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH 2/2] Documentation: sched/deadline: Update GRUB description
Date: Wed, 10 May 2023 15:05:01 +0700	[thread overview]
Message-ID: <b97d63e4-0ff7-720b-30d7-ad27611e9a8c@gmail.com> (raw)
In-Reply-To: <20230508160829.2756405-2-vineeth@bitbyteword.org>

On 5/8/23 23:08, Vineeth Pillai wrote:
> diff --git a/Documentation/scheduler/sched-deadline.rst b/Documentation/scheduler/sched-deadline.rst
> index 9d9be52f221a..0c73f07f712d 100644
> --- a/Documentation/scheduler/sched-deadline.rst
> +++ b/Documentation/scheduler/sched-deadline.rst
> @@ -195,11 +195,15 @@ Deadline Task Scheduling
>        its utilization is added to the active utilization of the runqueue where
>        it has been enqueued.
>  
> - For each runqueue, the algorithm GRUB keeps track of two different bandwidths:
> + For each runqueue, the algorithm GRUB keeps track of three different bandwidths:
>  
>    - Active bandwidth (running_bw): this is the sum of the bandwidths of all
>      tasks in active state (i.e., ActiveContending or ActiveNonContending);
>  
> +  - Active bandwidth of SCHED_FLAG_RECLAIM tasks(reclaim_bw): this is the sum of
> +    bandwidth of all tasks in active state which participates in GRUB. This is a
> +    subset of running_bw and is needed for reclaimable bandwidth calculation.
> +
>    - Total bandwidth (this_bw): this is the sum of all tasks "belonging" to the
>      runqueue, including the tasks in Inactive state.
>  
> @@ -209,12 +213,12 @@ Deadline Task Scheduling
>   to
>  
>             dq = -max{ Ui / Umax, (1 - Uinact - Uextra) } dt
> +           dq = -(Ureclaim / (Uextra + Uinact + Ureclaim)) dt
>  
>   where:
>  
> -  - Ui is the bandwidth of task Ti;
> -  - Umax is the maximum reclaimable utilization (subjected to RT throttling
> -    limits);
> +  - Ureclaim is the (per runqueue) bandwidth of all SCHED_FLAG_RECLAIM tasks
> +    in active state;
>    - Uinact is the (per runqueue) inactive utilization, computed as
>      (this_bq - running_bw);
>    - Uextra is the (per runqueue) extra reclaimable utilization
> @@ -222,7 +226,8 @@ Deadline Task Scheduling
>  
>  
>   Let's now see a trivial example of two deadline tasks with runtime equal
> - to 4 and period equal to 8 (i.e., bandwidth equal to 0.5)::
> + to 4 and period equal to 8 (i.e., bandwidth equal to 0.5). Tasks are
> + allowed to use the whole cpu(Umax = 1)::
>  
>           A            Task T1
>           |
> @@ -244,7 +249,7 @@ Deadline Task Scheduling
>           0   1   2   3   4   5   6   7   8
>  
>  
> -         A            running_bw
> +         A            reclaim_bw
>           |
>         1 -----------------               ------
>           |               |               |
> @@ -272,7 +277,7 @@ Deadline Task Scheduling
>  
>      This is the 0-lag time for Task T1. Since it didn't woken up in the
>      meantime, it enters the Inactive state. Its bandwidth is removed from
> -    running_bw.
> +    running_bw and reclaim_bw.
>      Task T2 continues its execution. However, its runtime is now decreased as
>      dq = - 0.5 dt because Uinact = 0.5.
>      Task T2 therefore reclaims the bandwidth unused by Task T1.
> @@ -280,7 +285,7 @@ Deadline Task Scheduling
>    - Time t = 8:
>  
>      Task T1 wakes up. It enters the ActiveContending state again, and the
> -    running_bw is incremented.
> +    running_bw and reclaim_bw are incremented.
>  
>  
>  2.3 Energy-aware scheduling

LGTM, thanks!

Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>

-- 
An old man doll... just what I always wanted! - Clara


  reply	other threads:[~2023-05-10  8:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-08 16:08 [PATCH 1/2] sched/deadline: accurate reclaim bandwidth for GRUB Vineeth Pillai
2023-05-08 16:08 ` [PATCH 2/2] Documentation: sched/deadline: Update GRUB description Vineeth Pillai
2023-05-10  8:05   ` Bagas Sanjaya [this message]
2023-05-09 11:25 ` [PATCH 1/2] sched/deadline: accurate reclaim bandwidth for GRUB luca abeni
2023-05-09 19:29   ` Vineeth Remanan Pillai
2023-05-09 20:48     ` luca abeni
2023-05-09 20:54       ` luca abeni
2023-05-10  3:53         ` Vineeth Remanan Pillai
2023-05-10  7:07           ` luca abeni
2023-05-10 15:50             ` Vineeth Remanan Pillai
2023-05-11  7:37               ` luca abeni
2023-05-11 18:34                 ` Vineeth Remanan Pillai
2023-05-11 20:03                   ` luca abeni
2023-05-11 20:40                     ` Vineeth Remanan Pillai
2023-05-15  2:56                       ` Vineeth Remanan Pillai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b97d63e4-0ff7-720b-30d7-ad27611e9a8c@gmail.com \
    --to=bagasdotme@gmail.com \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=corbet@lwn.net \
    --cc=dietmar.eggemann@arm.com \
    --cc=joel@joelfernandes.org \
    --cc=juri.lelli@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca.abeni@santannapisa.it \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vineeth@bitbyteword.org \
    --cc=vschneid@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®