LKML Archive on
help / color / mirror / Atom feed
From: Jongseok Kim <>
To: Vitaly Wool <>
Cc:, Jongseok Kim <>
Subject: Re: [PATCH v2] z3fold: fix reclaim lock-ups
Date: Wed,  9 May 2018 15:11:59 +0900	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> Hi Jongseok,

> I don't see how that is relevant, we don't use zhdr variable if the page is
headless anyway.

> Thanks, that is indeed a valid fix, but given the operation of eviction in
> zswap case, I'd prefer to release the page here and not in _free().
> Basically we should bail very early from z3fold_free() if the page is
> headless and UNDER_RECLAIM and keep the code intact in
> z3fold_reclaim_page().

> ~Vitaly

Hi, Vitaly. Thanks for your reply.
Then I think the below code is your preferred code.

And explaining about zhdr, this code don't mean that zhdr pointer is 
used as z3fold_header. Because it's headless like you said. 
Even though it is headless, however, 'zhdr', the pointer of z3fold_header,
is still used in _alloc and encode_handle as an address of a headless page.

So in pervious code, if eviction fails (it's not headless) and the selected page
in the next try loop is headless, then 'zhdr' will remain the value of the
previously failed page, which will cause a not headless page to be encoded
to headless. This is why a page that is not headless is encoded as HEADLESS 
in _map, which causes 'z3fold: unknown buddy id 0' warning.

And I have a one question. In z3fold_reclaim_page, is it because of 
performance that you added non-headless pages only to lru list
except buddy list?


 mm/z3fold.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/mm/z3fold.c b/mm/z3fold.c
index d5b3f49..5f659ab 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -746,6 +746,9 @@ static void z3fold_free(struct z3fold_pool *pool, unsigned long handle)
 	if (bud == HEADLESS) {
+		if (test_bit(UNDER_RECLAIM, &page->private))
+			return;
@@ -836,11 +839,11 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
 		list_for_each_prev(pos, &pool->lru) {
 			page = list_entry(pos, struct page, lru);
+			zhdr = page_address(page);
 			if (test_bit(PAGE_HEADLESS, &page->private))
 				/* candidate found */
-			zhdr = page_address(page);
 			if (!z3fold_page_trylock(zhdr))
 				continue; /* can't evict at this point */
@@ -898,6 +901,7 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
 		if (test_bit(PAGE_HEADLESS, &page->private)) {
 			if (ret == 0) {
+				atomic64_dec(&pool->pages_nr);
 				return 0;

  reply	other threads:[~2018-05-09  6:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-03  6:36 Jongseok Kim
2018-05-06  9:39 ` Vitaly Wool
2018-05-09  6:11   ` Jongseok Kim [this message]
2018-05-11  4:55     ` Jongseok Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: [PATCH v2] z3fold: fix reclaim lock-ups' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).