[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAF8kJuMoOZYySOFev46uMxdwvVjFbfCTSKeHywrazN-VUxJyoA@mail.gmail.com>
Date: Fri, 27 Sep 2024 15:59:11 -0700
From: Chris Li <chrisl@...nel.org>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: Venkat Rao Bagalkote <venkat88@...ux.vnet.ibm.com>, Andrew Morton <akpm@...ux-foundation.org>,
Andrey Skvortsov <andrej.skvortzov@...il.com>, Minchan Kim <minchan@...nel.org>,
Jens Axboe <axboe@...nel.dk>, linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
stable@...r.kernel.org, Sachin Sant <sachinp@...ux.ibm.com>,
linux-mm <linux-mm@...ck.org>
Subject: Re: [PATCH v3] zram: don't free statically defined names
On Tue, Sep 24, 2024 at 9:04 PM Chris Li <chrisl@...nel.org> wrote:
>
> On Tue, Sep 24, 2024 at 5:37 PM Sergey Senozhatsky
> <senozhatsky@...omium.org> wrote:
> >
> > On (24/09/24 11:29), Chris Li wrote:
> > > On Tue, Sep 24, 2024 at 8:56 AM Chris Li <chrisl@...nel.org> wrote:
> > [..]
> > > Given the merge window is closing. I suggest just reverting this
> > > change. As it is the fix also causing regression in the swap stress
> > > test for me. It is possible that is my test setup issue, but reverting
> > > sounds the safe bet.
> >
> > The patch in question is just a kfree() call that is only executed
> > during zram reset and that fixes tiny memory leaks when zram is
> > configured with alternative (re-compression) streams. I cannot
> > imagine how that can have any impact on runtime, that makes no
> > sense to me, I'm not sure that revert is justified here.
> >
> After some discussion with Sergey, we have more progress on
> understanding the swap stress test regression.
> One of the triggering conditions is I don't have zram lz4 config
> enabled, (the config option name has changed) and the test script
> tries to set lz4 on zram and fails. It will fall back to the lzo.
> Anyway, if I have zram lz4 configured, my stress test can pass with
> the fix. Still I don't understand why disabling lz4 config can trigger
> it. Need to dig more.
>
> Agree that we don't need to revert this.
Turns out that my oom kill is a false alarm. After some debug
discussion with Sergey, I confirm the fix works. The cause of the oom
kill is because my bisect script did not apply one of the known fix
patches after applying Andrey Skvortsov's fix in this thread. Sorry
about the confusion I created.
Feel free to add:
Tested-by: Chris Li <chrisl@...nel.org>
Hi Andrew,
FYI, the tip of current mm-stable
abf2050f51fdca0fd146388f83cddd95a57a008d is failing my swap stress
test, missing the fix in this email thread.
Adding this fix 486fd58af7ac1098b68370b1d4d9f94a2a1c7124 to mm-stable
will make mm-stable pass the stress test.
Current tip of mm-unstable 66af62407e82647ec5b44462dc29d50ba03fdb22 is
passing my swap stress test fine.
Chris
Powered by blists - more mailing lists