From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Brian Geffon <bgeffon@google.com>, Minchan Kim <minchan@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Nitin Gupta <ngupta@vflare.org>,
linux-kernel@vger.kernel.org,
Suleiman Souhlal <suleiman@google.com>,
Rom Lemarchand <romlem@google.com>,
linux-mm@kvack.org, Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: [RESEND RFC] zram: Allow rw_page when page isn't written back.
Date: Mon, 12 Sep 2022 13:37:15 +0900 [thread overview]
Message-ID: <Yx63e2lxNmEB3UhE@google.com> (raw)
In-Reply-To: <Yxr5oNaCwjn8cdFF@google.com>
On (22/09/09 17:30), Sergey Senozhatsky wrote:
> > +++ b/drivers/block/zram/zram_drv.h
> > @@ -50,6 +50,7 @@ enum zram_pageflags {
> > ZRAM_UNDER_WB, /* page is under writeback */
> > ZRAM_HUGE, /* Incompressible page */
> > ZRAM_IDLE, /* not accessed page since last idle marking */
> > + ZRAM_NO_WB, /* Do not allow page to be written back */
> >
> > __NR_ZRAM_PAGEFLAGS,
> > };
>
> Unrelated but somehow related.
>
> I wonder if it's time for us to introduce a dedicated, say u16,
> flags member to struct zram_table_entry. Unless my calculations
> are extremely wrong, we are about to run out of spare bits in
> zram_table_entry::flags on 32-bit systems.
Looking at it more - I wonder why do we define ZRAM_FLAG_SHIFT
as 24? This is far more than maximum zram object size. Our max
size needs PAGE_SHIFT bits (which is normally 12 bits, can be up
to 16 (for 64k arm64 pages)). So we probably can start defining
ZRAM_FLAG_SHIFT as (PAGE_SHIFT + 1).
Or am I missing something?
---
diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
index b4eecef2a11f..cb8f1f644baf 100644
--- a/drivers/block/zram/zram_drv.h
+++ b/drivers/block/zram/zram_drv.h
@@ -39,7 +39,7 @@
* The lower ZRAM_FLAG_SHIFT bits is for object size (excluding header),
* the higher bits is for zram_pageflags.
*/
-#define ZRAM_FLAG_SHIFT 24
+#define ZRAM_FLAG_SHIFT (PAGE_SHIFT + 1)
/* Flags for zram pages (table[page_no].flags) */
enum zram_pageflags {
next prev parent reply other threads:[~2022-09-12 4:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-08 12:50 [RESEND RFC] zram: Allow rw_page when page isn't written back Brian Geffon
2022-09-09 8:30 ` Sergey Senozhatsky
2022-09-12 4:37 ` Sergey Senozhatsky [this message]
2022-09-12 6:07 ` Sergey Senozhatsky
2022-09-23 19:31 ` Minchan Kim
2022-09-30 19:33 ` Brian Geffon
2022-09-30 19:52 ` [PATCH] zram: Always expose rw_page Brian Geffon
2022-10-03 2:59 ` Sergey Senozhatsky
2022-10-03 14:46 ` Brian Geffon
2022-10-03 14:48 ` [PATCH v2] " Brian Geffon
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yx63e2lxNmEB3UhE@google.com \
--to=senozhatsky@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=bgeffon@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=ngupta@vflare.org \
--cc=romlem@google.com \
--cc=suleiman@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.