mbox series

[RFC,00/25] mm/zsmalloc: Split zsdesc from struct page

Message ID 20230220132218.546369-1-42.hyeyoo@gmail.com (mailing list archive)
Headers show
Series mm/zsmalloc: Split zsdesc from struct page | expand

Message

Hyeonggon Yoo Feb. 20, 2023, 1:21 p.m. UTC
[Maybe not the best time to send patch series, but just wanted to
 get some early feedback from zsmalloc maintainers]

The purpose of this series is to define own memory descriptor for zsmalloc,
instead of re-using various fields of struct page. This is a part of the
effort to reduce the size of struct page to unsigned long and enable
dynamic allocation of memory descriptors.

While [1] outlines this ultimate objective, the current use of struct page
is highly interdependent, making it challenging to separately allocate
memory descriptors.

Therefore, this series introduces new descriptor for zsmalloc, called
zsdesc. It overlays struct page for now, but will eventually be allocated
independently in the future. And apart from dynamic allocation of descriptors,
this is a nice cleanup.

I have no strong opinion about its name. I was thinking about between
zsmem and zsdesc, and wanted to be consistent with struct ptdesc.
(which is AFAIK work in progress)

This work is also available at:
	https://gitlab.com/hyeyoo/linux/-/tree/separate_zsdesc_rfc-v1

Any feedbacks would be appreciated!

[1] State Of The Page, August 2022
https://lore.kernel.org/lkml/YvV1KTyzZ+Jrtj9x@casper.infradead.org

Best regards,
Hyeonggon

Hyeonggon Yoo (25):
  mm/zsmalloc: create new struct zsdesc
  mm/zsmalloc: add utility functions for zsdesc
  mm/zsmalloc: replace first_page to first_zsdesc in struct zspage
  mm/zsmalloc: add alternatives of frequently used helper functions
  mm/zsmalloc: convert {try,}lock_zspage() to use zsdesc
  mm/zsmalloc: convert __zs_{map,unmap}_object() to use zsdesc
  mm/zsmalloc: convert obj_to_location() and its users to use zsdesc
  mm/zsmalloc: convert obj_malloc() to use zsdesc
  mm/zsmalloc: convert create_page_chain() and its users to use zsdesc
  mm/zsmalloc: convert obj_tagged() and related helpers to use zsdesc
  mm/zsmalloc: convert init_zspage() to use zsdesc
  mm/zsmalloc: convert obj_to_page() and zs_free() to use zsdesc
  mm/zsmalloc: convert reset_page() to reset_zsdesc()
  mm/zsmalloc: convert zs_page_{isolate,migrate,putback} to use zsdesc
  mm/zsmalloc: convert __free_zspage() to use zsdesc
  mm/zsmalloc: convert unlock_zspage() to use zsdesc
  mm/zsmalloc: convert location_to_obj() to use zsdesc
  mm/zsmalloc: convert free_handles() to use zsdesc
  mm/zsmalloc: convert zs_compact_control and its users to use zsdesc
  mm/zsmalloc: convert get_zspage() to take zsdesc
  mm/zsmalloc: convert SetZsPageMovable() to use zsdesc
  mm/zsmalloc: convert restore_freelist() to use zsdesc
  mm/zsmalloc: convert zs_reclaim_page() to use zsdesc
  mm/zsmalloc: remove now unused helper functions
  mm/zsmalloc: convert {get,set}_first_obj_offset() to use zsdesc

 mm/zsmalloc.c | 707 ++++++++++++++++++++++++++++++--------------------
 1 file changed, 429 insertions(+), 278 deletions(-)

Comments

Minchan Kim Feb. 24, 2023, 12:01 a.m. UTC | #1
Hi Hyeonggon

On Mon, Feb 20, 2023 at 01:21:53PM +0000, Hyeonggon Yoo wrote:
> [Maybe not the best time to send patch series, but just wanted to
>  get some early feedback from zsmalloc maintainers]
> 
> The purpose of this series is to define own memory descriptor for zsmalloc,
> instead of re-using various fields of struct page. This is a part of the
> effort to reduce the size of struct page to unsigned long and enable
> dynamic allocation of memory descriptors.
> 
> While [1] outlines this ultimate objective, the current use of struct page
> is highly interdependent, making it challenging to separately allocate
> memory descriptors.
> 
> Therefore, this series introduces new descriptor for zsmalloc, called
> zsdesc. It overlays struct page for now, but will eventually be allocated
> independently in the future. And apart from dynamic allocation of descriptors,
> this is a nice cleanup.
> 
> I have no strong opinion about its name. I was thinking about between
> zsmem and zsdesc, and wanted to be consistent with struct ptdesc.
> (which is AFAIK work in progress)

I wanted to have the chance to take a look zsmalloc folio stuff but
couldn't set up some time. :( Thanks for the good work, Hyeonggon!

I will take a look once when I am available.
Just FYI, Sergey was doing some changes in zsmalloc
https://lore.kernel.org/linux-mm/20230223030451.543162-1-senozhatsky@chromium.org/
I guess this patch would conflict with it so may need to rebase
once they were merged. Anyway, Regardless of that, I will review
this patch as soon as finishing urgent stuff.

Thanks.
Hyeonggon Yoo Feb. 28, 2023, 12:32 a.m. UTC | #2
On Thu, Feb 23, 2023 at 04:01:54PM -0800, Minchan Kim wrote:
> Hi Hyeonggon

Hi Minchan.

> On Mon, Feb 20, 2023 at 01:21:53PM +0000, Hyeonggon Yoo wrote:
> > [Maybe not the best time to send patch series, but just wanted to
> >  get some early feedback from zsmalloc maintainers]
> > 
> > The purpose of this series is to define own memory descriptor for zsmalloc,
> > instead of re-using various fields of struct page. This is a part of the
> > effort to reduce the size of struct page to unsigned long and enable
> > dynamic allocation of memory descriptors.
> > 
> > While [1] outlines this ultimate objective, the current use of struct page
> > is highly interdependent, making it challenging to separately allocate
> > memory descriptors.
> > 
> > Therefore, this series introduces new descriptor for zsmalloc, called
> > zsdesc. It overlays struct page for now, but will eventually be allocated
> > independently in the future. And apart from dynamic allocation of descriptors,
> > this is a nice cleanup.
> > 
> > I have no strong opinion about its name. I was thinking about between
> > zsmem and zsdesc, and wanted to be consistent with struct ptdesc.
> > (which is AFAIK work in progress)
> 
> I wanted to have the chance to take a look zsmalloc folio stuff but
> couldn't set up some time. :( Thanks for the good work, Hyeonggon!

My pleasure :)

> I will take a look once when I am available.
> Just FYI, Sergey was doing some changes in zsmalloc
> https://lore.kernel.org/linux-mm/20230223030451.543162-1-senozhatsky@chromium.org/
> I guess this patch would conflict with it so may need to rebase
> once they were merged.

Sure. I'll rebase as they are already in mm-unstable.

> Anyway, Regardless of that, I will review
> this patch as soon as finishing urgent stuff.

No problem, thank you so much!

> 
> Thanks.
Sergey Senozhatsky Feb. 28, 2023, 2:02 a.m. UTC | #3
On (23/02/28 00:32), Hyeonggon Yoo wrote:
> > I wanted to have the chance to take a look zsmalloc folio stuff but
> > couldn't set up some time. :( Thanks for the good work, Hyeonggon!
> 
> My pleasure :)
> 
> > I will take a look once when I am available.
> > Just FYI, Sergey was doing some changes in zsmalloc
> > https://lore.kernel.org/linux-mm/20230223030451.543162-1-senozhatsky@chromium.org/
> > I guess this patch would conflict with it so may need to rebase
> > once they were merged.
> 
> Sure. I'll rebase as they are already in mm-unstable.

The seies that is currenly in mm-unstable will be rebased, we
probably will land a new version by the end of this week.

> > Anyway, Regardless of that, I will review
> > this patch as soon as finishing urgent stuff.
> 
> No problem, thank you so much!

Thank you.