linux-kernel - Re: [PATCH 00/15] Introduce DAMON-based Proactive Reclamation

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: <20211123083636.5603-1-sj@kernel.org>
Date:   Tue, 23 Nov 2021 08:36:36 +0000
From:   SeongJae Park <sj@...nel.org>
To:     Oleksandr Natalenko <oleksandr@...alenko.name>
Cc:     akpm@...ux-foundation.org, SeongJae Park <sj@...nel.org>,
        Jonathan.Cameron@...wei.com, amit@...nel.org,
        benh@...nel.crashing.org, corbet@....net, david@...hat.com,
        dwmw@...zon.com, elver@...gle.com, foersleo@...zon.de,
        gthelen@...gle.com, markubo@...zon.de, rientjes@...gle.com,
        shakeelb@...gle.com, shuah@...nel.org, linux-damon@...zon.com,
        linux-mm@...ck.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/15] Introduce DAMON-based Proactive Reclamation

Hello Oleksandr,

On Sun, 21 Nov 2021 23:32:12 +0100 Oleksandr Natalenko <oleksandr@...alenko.name> wrote:

> Hello.
> 
> On úterý 19. října 2021 17:07:16 CET SeongJae Park wrote:
> > In short, DAMON_RECLAIM with 50ms/s time quota and regions prioritization on
> > v5.15-rc5 Linux kernel with ZRAM swap device achieves 38.58% memory saving
> > with only 1.94% runtime overhead.  For this, DAMON_RECLAIM consumes only
> > 4.97% of single CPU time.
> 
> While it really consumes little CPU time, is it fine for `kdamond.0` to be in a 
> D (uninterruptible sleep) state all the time while active, pushing loadavg 
> over 1.0?

Good point, this could confuse some users using loadavg.  I will send a fix for
this soon.


Thanks,
SJ

> 
> Thanks.
> 
> -- 
> Oleksandr Natalenko (post-factum)
>