From: Alex Shi <seakeel@gmail.com>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Matthew Wilcox <willy@infradead.org>,
Yosry Ahmed <yosryahmed@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
alexs@kernel.org, Vitaly Wool <vitaly.wool@konsulko.com>,
Miaohe Lin <linmiaohe@huawei.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
minchan@kernel.org, david@redhat.com, 42.hyeyoo@gmail.com,
nphamcs@gmail.com
Subject: Re: [PATCH v5 00/21] mm/zsmalloc: add zpdesc memory descriptor for zswap.zpool
Date: Thu, 15 Aug 2024 11:50:37 +0800 [thread overview]
Message-ID: <5f785814-0be0-407f-87a0-4bfb4041fa2d@gmail.com> (raw)
In-Reply-To: <20240815031314.GA12106@google.com>
On 8/15/24 11:13 AM, Sergey Senozhatsky wrote:
> On (24/08/09 10:32), Alex Shi wrote:
> [..]
>>>> and we "chain" zpdesc-s to form a zspage, and make each of them point to
>>>> a corresponding struct page (memdesc -> *page), then it'll resemble current
>>>> zsmalloc and should work for everyone? I also assume for zspdesc-s zsmalloc
>>>> will need to maintain a dedicated kmem_cache?
>>> Right, we could do that. Each memdesc has to be a multiple of 16 bytes,
>>> sp we'd be doing something like allocating 32 bytes for each page.
>>> Is there really 32 bytes of information that we want to store for
>>> each page? Or could we store all of the information in (a somewhat
>>> larger) zspage? Assuming we allocate 3 pages per zspage, if we allocate
>>> an extra 64 bytes in the zspage, we've saved 32 bytes per zspage.
>>
>> Thanks for the suggestions! Yes, it's a good direction we could try after this
>> patchset.
>
> Alex, may I ask what exactly you will "try"?
Hi Sergey,
Thanks for question. As a quick amateur thought, the final result may like following,
please correct me if I am wrong.
1, there is a memdesc for each of memory page.
2, we kmem_alloc some zpdesc struct for specifically our needs, like zpdesc.next
zpdesc.zspage/first_obj_offset, these current we used in zsmalloc.
3, there is a gap between memdesc and zpdesc, like .flags, _refcount, .mops etc.
this part is still unclear that how to handle them well.
During the 2nd, 3rd steps, we may have chance to move some members from zpdesc, to
zspage? but it's also unclear.
Thanks
Alex
next prev parent reply other threads:[~2024-08-15 3:50 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-06 2:21 alexs
2024-08-06 2:22 ` alexs
2024-08-06 2:22 ` [PATCH v5 01/21] " alexs
2024-08-06 2:22 ` [PATCH v5 02/21] mm/zsmalloc: use zpdesc in trylock_zspage()/lock_zspage() alexs
2024-08-06 2:22 ` [PATCH v5 03/21] mm/zsmalloc: convert __zs_map_object/__zs_unmap_object to use zpdesc alexs
2024-08-06 2:22 ` [PATCH v5 04/21] mm/zsmalloc: add and use pfn/zpdesc seeking funcs alexs
2024-08-06 2:22 ` [PATCH v5 05/21] mm/zsmalloc: convert obj_malloc() to use zpdesc alexs
2024-08-06 2:22 ` [PATCH v5 06/21] mm/zsmalloc: convert create_page_chain() and its users " alexs
2024-08-06 2:22 ` [PATCH v5 07/21] mm/zsmalloc: convert obj_allocated() and related helpers " alexs
2024-08-06 2:22 ` [PATCH v5 08/21] mm/zsmalloc: convert init_zspage() " alexs
2024-08-06 2:22 ` [PATCH v5 09/21] mm/zsmalloc: convert obj_to_page() and zs_free() " alexs
2024-08-06 2:22 ` [PATCH v5 10/21] mm/zsmalloc: add zpdesc_is_isolated()/zpdesc_zone() helper for zs_page_migrate() alexs
2024-08-06 2:22 ` [PATCH v5 11/21] mm/zsmalloc: rename reset_page to reset_zpdesc and use zpdesc in it alexs
2024-08-06 2:22 ` [PATCH v5 12/21] mm/zsmalloc: convert __free_zspage() to use zdsesc alexs
2024-08-06 2:23 ` [PATCH v5 13/21] mm/zsmalloc: convert location_to_obj() to take zpdesc alexs
2024-08-06 2:23 ` [PATCH v5 14/21] mm/zsmalloc: convert migrate_zspage() to use zpdesc alexs
2024-08-06 2:23 ` [PATCH v5 15/21] mm/zsmalloc: convert get_zspage() to take zpdesc alexs
2024-08-06 2:23 ` [PATCH v5 16/21] mm/zsmalloc: convert SetZsPageMovable and remove unused funcs alexs
2024-08-06 2:23 ` [PATCH v5 17/21] mm/zsmalloc: convert get/set_first_obj_offset() to take zpdesc alexs
2024-08-06 2:23 ` [PATCH v5 18/21] mm/zsmalloc: introduce __zpdesc_clear_movable alexs
2024-08-06 2:23 ` [PATCH v5 19/21] mm/zsmalloc: introduce __zpdesc_clear/set_zsmalloc() alexs
2024-08-06 2:23 ` [PATCH v5 20/21] mm/zsmalloc: introduce zpdesc_clear_first() helper alexs
2024-08-06 2:23 ` [PATCH v5 21/21] mm/zsmalloc: update comments for page->zpdesc changes alexs
[not found] ` <20240806123213.2a747a8321bdf452b3307fa9@linux-foundation.org>
[not found] ` <CAJD7tkakcaLVWi0viUqaW0K81VoCuGmkCHN4KQXp5+SSJLMB9g@mail.gmail.com>
[not found] ` <20240807051754.GA428000@google.com>
[not found] ` <ZrQ9lrZKWdPR7Zfu@casper.infradead.org>
2024-08-09 2:32 ` [PATCH v5 00/21] mm/zsmalloc: add zpdesc memory descriptor for zswap.zpool Alex Shi
2024-08-15 3:13 ` Sergey Senozhatsky
2024-08-15 3:50 ` Alex Shi [this message]
2024-08-14 6:03 ` Sergey Senozhatsky
2024-08-27 23:19 ` Vishal Moola
2024-08-29 9:42 ` Alex Shi
2024-09-04 19:51 ` Vishal Moola
2024-09-04 20:21 ` Yosry Ahmed
2024-09-03 3:20 ` Sergey Senozhatsky
2024-09-03 17:35 ` Vishal Moola
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=5f785814-0be0-407f-87a0-4bfb4041fa2d@gmail.com \
--to=seakeel@gmail.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alexs@kernel.org \
--cc=david@redhat.com \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=nphamcs@gmail.com \
--cc=senozhatsky@chromium.org \
--cc=vitaly.wool@konsulko.com \
--cc=willy@infradead.org \
--cc=yosryahmed@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox