[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJD7tkah9kx2kAcTY47J2R5p7NYS+b+3A9S_R-hSv9z8OSzzqA@mail.gmail.com>
Date: Mon, 17 Apr 2023 04:16:24 -0700
From: Yosry Ahmed <yosryahmed@...gle.com>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: Yu Zhao <yuzhao@...gle.com>, Minchan Kim <minchan@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCHv4 0/4] zsmalloc: fine-grained fullness and new compaction algorithm
On Mon, Apr 17, 2023 at 4:12 AM Sergey Senozhatsky
<senozhatsky@...omium.org> wrote:
>
> On (23/04/17 01:29), Yosry Ahmed wrote:
> > > @@ -2239,8 +2241,8 @@ static unsigned long __zs_compact(struct zs_pool *pool,
> > > if (fg == ZS_INUSE_RATIO_0) {
> > > free_zspage(pool, class, src_zspage);
> > > pages_freed += class->pages_per_zspage;
> > > - src_zspage = NULL;
> > > }
> > > + src_zspage = NULL;
> > >
> > > if (get_fullness_group(class, dst_zspage) == ZS_INUSE_RATIO_100
> > > || spin_is_contended(&pool->lock)) {
> >
> > For my own education, how can this result in the "next is NULL" debug
> > error Yu Zhao is seeing?
> >
> > IIUC if we do not set src_zspage to NULL properly after putback, then
> > we will attempt to putback again after the main loop in some cases.
> > This can result in a zspage being present more than once in the
> > per-class fullness list, right?
> >
> > I am not sure how this can lead to "next is NULL", which sounds like a
> > corrupted list_head, because the next ptr should never be NULL as far
> > as I can tell. I feel like I am missing something.
>
> That's a good question to which I don't have an answer. We can list_add()
> the same zspage twice, unlocking the pool after first list_add() so that
> another process (including another zs_compact()) can do something to that
> zspage. The answer is somewhere between these lines, I guess.
But the first list_add() is (in this case) the correct add, so we
expect other processes to be able to access the zspage after the first
list_add() anyway, right?
>
> I can see how, for example, another DEBUG_LIST check can be triggered:
> "list_add double add", because we basically can do
>
> list_add(page, list)
> list_add(page, list)
>
> I can also see how lockdep can be unhappy with us doing
>
> write_unlock(&zspage->lock);
> write_unlock(&zspage->lock);
>
> But I don't think I see how "next is NULL" happens (I haven't observed
> it).
Yeah I reached the same conclusion. Couldn't figure out how we can
reach the NULL scenario.
Powered by blists - more mailing lists