[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220524064416.GB774480@hori.linux.bs1.fc.nec.co.jp>
Date: Tue, 24 May 2022 06:44:16 +0000
From: HORIGUCHI NAOYA(堀口 直也)
<naoya.horiguchi@....com>
To: Miaohe Lin <linmiaohe@...wei.com>
CC: "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"hughd@...gle.com" <hughd@...gle.com>,
"willy@...radead.org" <willy@...radead.org>,
"vbabka@...e.cz" <vbabka@...e.cz>,
"dhowells@...hat.com" <dhowells@...hat.com>,
"neilb@...e.de" <neilb@...e.de>,
"apopple@...dia.com" <apopple@...dia.com>,
"david@...hat.com" <david@...hat.com>,
"surenb@...gle.com" <surenb@...gle.com>,
"peterx@...hat.com" <peterx@...hat.com>,
"rcampbell@...dia.com" <rcampbell@...dia.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 4/5] mm/shmem: fix infinite loop when swap in shmem
error at swapoff time
On Mon, May 23, 2022 at 07:23:53PM +0800, Miaohe Lin wrote:
...
> >
> > I reproduced the deadloop issues when swapin error occurs at swapoff time in my linux-next-next-20220520 env,
> > and I found this patch could solve the issue now with the fix in my another email.
> >
> > BTW: When I use dm-dust to inject the swapin IO error, I don't see non-uptodate folio when shmem_swapin_folio
> > and swapoff succeeds. There might be some issues around that module (so I resort to the another way to inject
> > the swapin error), but the patch itself works anyway. ;)
>
> Sorry, the reason I don't see non-uptodate folio when shmem_swapin_folio is that all the shmem pages are still
> in the swapcache. They're not read from disk so there is no really IO error. :) When they're indeed freed, the
> deadloop issue occurs.
>
> I am thinking about extending the function of MADV_PAGEOUT to free the swapcache page. The page resides in the
> swapcache does not save the system memory anyway. And this could help test the swapin behavior. But I'm not
> sure whether it's needed.
The extension make MADV_PAGEOUT free swapcaches makes sense to me,
so I'll support it if the original implementer agrees the change.
Thanks,
Naoya Horiguchi
Powered by blists - more mailing lists