linux-kernel - Re: [PATCHv2] zsmalloc: allow only one active pool compaction context

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: <CAJD7tkbi81tCXvTqEHVums_xr4572fSmdPa7A7Fb5Y-0JWQK0w@mail.gmail.com>
Date:   Tue, 18 Apr 2023 12:37:03 -0700
From:   Yosry Ahmed <yosryahmed@...gle.com>
To:     Sergey Senozhatsky <senozhatsky@...omium.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Minchan Kim <minchan@...nel.org>, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [PATCHv2] zsmalloc: allow only one active pool compaction context

On Tue, Apr 18, 2023 at 4:24 AM Sergey Senozhatsky
<senozhatsky@...omium.org> wrote:
>
> On (23/04/17 19:53), Yosry Ahmed wrote:
> >
> > As for this patch, I personally do not observe a lot of compaction in
> > our production environment, and allowing one thread to perform
> > compaction while others move on with their lives can be better than
> > having all of them continuously contending for the pool->lock, which
> > means more contention with ~all zsmalloc operations, not just
> > concurrent compactors. I can't say for sure that this is an
> > improvement, but I *believe* it is.
>
> Looking at one of ChromeOS memory-pressure tests, I see that sometimes
> (albeit rarely) we can have up to 9 parallel zspool compaction contexts,
> perhaps a little bit too many for a 12 CPUs laptop:
>
> [ 2159.378827] zsmalloc: ctx #1 chrome -> zs_compact()
> [ 2159.379002] zsmalloc: ctx #2 Chrome_ChildIOT -> zs_compact()
> [ 2159.379120] zsmalloc: ctx #3 chrome -> zs_compact()
> [ 2159.379135] zsmalloc: ctx #4 chrome -> zs_compact()
> [ 2159.379213] zsmalloc: ctx #5 chrome -> zs_compact()
> [ 2159.379271] zsmalloc: ctx #6 chrome -> zs_compact()
> [ 2159.379276] zsmalloc: ctx #7 chrome -> zs_compact()
> [ 2159.382786] zsmalloc: ctx #8 chrome -> zs_compact()
> [ 2159.432153] zsmalloc: ctx #9 kswapd0 -> zs_compact()


I haven't looked into such pressure tests on our end, the information
I have is based on the amount of CPU cycles we are spending on
zsmalloc compaction in general.