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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 9 May 2023 23:53:28 -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

On Tue, May 9, 2023 at 4:54 PM luca abeni <luca.abeni@...tannapisa.it> wrote:

> > Yes, this is the approximation I was mentioning... Instead of using a
> > division, I approximated it with a different equation using a sum.
>
> Sorry, ignore this comment (and the following); I misinterpreted the
> code (and my old notes).
>
> I do not understand why the "max{}" doe not work well, I need to double
> think about it.
>
I was thinking more about this and was doing some more digging into
this. I was also wrong about min{}. Giving it some more thought, I think
(U/Umax) is indeed the only equation we need and it will take care
of caping the reclaiming at Umax. The reason why it was not working
is because of the loss of precision when we did the inverse. I tried
replacing (delta * running_bw * bw_ratio) by
div64_u64(delta * running_bw, Umax) and it worked as expected and
reclaimed only till Umax with only SCHED_FLAG_RECLAIM tasks. As an
example a task with reservation (1, 100) and RT capacity 95%, and
delta = 4ms, we get scaled_delta as
delta * running_bw * bw_ratio ~= .040000 (roughly)
div64_u64(delta * running_bw, Umax) ~= .04210526 (roughly)

This caused the inverse logic to consume ~99% bw, while the other
one consumed ~95% as expected.

I still could not figure out why min{} works. As you mentioned in
the previous thread, its the loss of precision thats the culprit and
I think we only need U/Umax if we have enough precision. This along
with accounting for both type of tasks will be the solution.

I will look deeper into any performance issues with using div64_u64
over multiplication and shall let you know soon.

Thanks,
Vineeth