linux-kernel - Re: [PATCH 1/2] sched/deadline: accurate reclaim bandwidth for GRUB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAO7JXPiYL_1ePxcoH=mvGq05S75jmA3SLjDf=oe0wU4Ozm4hrA@mail.gmail.com>
Date:   Sun, 14 May 2023 22:56:55 -0400
From:   Vineeth Remanan Pillai <vineeth@...byteword.org>
To:     luca abeni <luca.abeni@...tannapisa.it>
Cc:     Juri Lelli <juri.lelli@...hat.com>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Joel Fernandes <joel@...lfernandes.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Valentin Schneider <vschneid@...hat.com>,
        Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org
Subject: Re: [PATCH 1/2] sched/deadline: accurate reclaim bandwidth for GRUB

Hi Luca,

> Sure, I shall split the patch. Joel also suggested splitting the patch
> and I was probably wrong to think that the patch was simple to be a
> single patch :-).
>
> Since equation (3) has theoretical backing, I am perfectly fine with
> using it for our fix. Will have 2 patches as you suggested.
>
> Will get the v3 out soon..
>
Sorry for the delay. I was testing the fixes and noticed one other
issue and was working on a fix.

This is with the extra_bw for tracking the unused bandwidth in the
system. As you have shown me:
 "extra_bw = Umax - ((Sum of bw of all tasks) / #cpus)"
But I noticed that tracking the extra_bw globally while rest of the
values as per-cpu causes issues with reclaiming especially when we
have tasks with small bandwidth. This is because GRUB tries to
proportionately divide unused bandwidth based on running bw on a cpu.
So even if there is only a single task in a cpu, it reclaims less if
its bandwidth is less.

I think removing the extra_bw and tracking unused bandwidth using
"max_bw - this_bw" should be okay. Since admission control will
guarantee that we don't admit more than the capacity, we should be
good with allowing tasks on a cpu to use max_bw while reclaiming.

With the above theory, the code becomes simpler and is the same as the
v2 patch.
 max{u_i, (max_bw - Uinact - Uextra)}
 = max {u_i, (max_bw - (this_bw - running_bw) - (max_bw - this_bw))}
 = max {u_i, running_bw} = running_bw
So, "dq = -(running_bw / max_bw) dt"

v2 had passed all my tests. But having Uextra broke couple of those
when it came to multiprocessors and after identifying the root cause
and re-writing the equation, everything works now and passes all
my tests. I have more confidence in the above equation as its derived
from the SMP GRUB rule using our max_bw.

Please have a look and let me know what you think about this.

I have the v3 ready with patches split into 5(including doc patch).
I shall post v3 soon after this so that you can see the code changes
as well to have a better look.

Thanks,
Vineeth