From: Alexey Romanov <AVRomanov@sberdevices.ru>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: "minchan@kernel.org" <minchan@kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
kernel <kernel@sberdevices.ru>
Subject: Re: [PATCH v1 1/2] zsmalloc: add allocated objects counter for subpage
Date: Tue, 20 Jun 2023 11:16:36 +0000 [thread overview]
Message-ID: <20230620111635.gztldehfzvuzkdnj@cab-wsm-0029881> (raw)
In-Reply-To: <20230620103629.GA42985@google.com>
Hello Sergey! Thank you for feedback.
On Tue, Jun 20, 2023 at 07:36:29PM +0900, Sergey Senozhatsky wrote:
> On (23/06/19 17:35), Alexey Romanov wrote:
> >
> > We use a variable of type unsigned int to store the offset
> > of the first object at the subpage In turn, the offset cannot
> > exceed the size of PAGE_SIZE, which is usually 4096. Thus,
> > 12 bits are enough to store the offset.
>
> [..]
>
> > If the page size is 4Kb
>
> It's certainly not a given. PAGE_SIZE is architecture specific.
> PAGE_SIZE_16KB and PAGE_SIZE_64KB would be simple examples, but there
> are, apparently, architectures that even can have PAGE_SIZE_256KB.
Sure.
As far I understand at the moment the maximum size of the page
(according to Kconfig info in linux sources) is 256Kb. In this case,
we need maximum 18 bits for storing offset. And 2^18 / 32 = 8192 bytes
(13 bits, I think u16 is OK for such purpose) for storing allocated
objects counter.
If sizeof(unsigned int) >= 32 bits the this will be enough for us.
Of course, in rare cases this will not be the case. But it seems that
zram and kernel already has similiar places. For example, if page size
is 256 Kb and sizeof(unsigned int) = 16 bits (2 byte), zram will not
wotk on such system, because we can't store offset. But such case is
very rare, most systems have unsigned int over 32 bits.
Therefore, I think that my idea is still applicable, we just need to
change the counter type. What do you think?
--
Thank you,
Alexey
next prev parent reply other threads:[~2023-06-20 11:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-19 14:35 [PATCH v1 0/2] Add obj allocated counter for subpages Alexey Romanov
2023-06-19 14:35 ` [PATCH v1 1/2] zsmalloc: add allocated objects counter for subpage Alexey Romanov
2023-06-20 10:36 ` Sergey Senozhatsky
2023-06-20 11:16 ` Alexey Romanov [this message]
2023-06-21 13:17 ` Sergey Senozhatsky
2023-06-21 13:41 ` Alexey Romanov
2023-06-21 13:55 ` Sergey Senozhatsky
2023-06-21 13:59 ` Alexey Romanov
2023-06-21 14:18 ` Sergey Senozhatsky
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=20230620111635.gztldehfzvuzkdnj@cab-wsm-0029881 \
--to=avromanov@sberdevices.ru \
--cc=akpm@linux-foundation.org \
--cc=kernel@sberdevices.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=senozhatsky@chromium.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox