[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230418112450.GT25053@google.com>
Date: Tue, 18 Apr 2023 20:24:50 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Yosry Ahmed <yosryahmed@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Sergey Senozhatsky <senozhatsky@...omium.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 (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()
Powered by blists - more mailing lists