linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH/RFC] Zram: Improved Compression with PID/VMA-aware Grouping
@ 2025-08-19 11:43 牛海程
  2025-08-20  8:49 ` Barry Song
  2025-08-21  3:11 ` Sergey Senozhatsky
  0 siblings, 2 replies; 3+ messages in thread
From: 牛海程 @ 2025-08-19 11:43 UTC (permalink / raw)
  To: minchan; +Cc: ngupta, sergey.senozhatsky.work, axboe, linux-kernel, linux-block

Dear Linux Kernel Zram Maintainers,

I am an open-source developer and have been working on some potential improvements to the Zram module, focusing on optimizing compression rates.My work is based on the Linux kernel version 5.10.240.

My recent work introduces the following changes:

1.PID and Virtual Address Tracking: During page swap-in operations at the swap layer, I've implemented a mechanism to record the Process ID (PID) and the corresponding virtual address of the page.
2.PID-aware Grouping and VMA Merging in Zram: Within the Zram layer, pages are now grouped based on their recorded PIDs. Following this grouping, pages with similar or contiguous virtual addresses within each PID group are merged before compression. The rationale behind this is that pages belonging to the same process and located adjacently in virtual memory are likely to contain related data, which could lead to better compression ratios when processed together.

Preliminary experiments using this approach have shown promising results:

With the LZ4 compression algorithm, we observed an approximate 3% increase in the overall compression rate.
With the ZSTD compression algorithm, the improvement was even more significant, reaching an approximate 4% increase in the overall compression rate.

I am writing to inquire if you believe this approach and its observed benefits are significant enough to warrant further consideration for upstreaming into the main Linux kernel. I would greatly appreciate your thoughts on the utility and potential implications of these changes, as well as any guidance on how to proceed with further development or formal submission.

Thank you for your time and consideration.
Best regards,
Haicheng Niu

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH/RFC] Zram: Improved Compression with PID/VMA-aware Grouping
  2025-08-19 11:43 [PATCH/RFC] Zram: Improved Compression with PID/VMA-aware Grouping 牛海程
@ 2025-08-20  8:49 ` Barry Song
  2025-08-21  3:11 ` Sergey Senozhatsky
  1 sibling, 0 replies; 3+ messages in thread
From: Barry Song @ 2025-08-20  8:49 UTC (permalink / raw)
  To: 牛海程
  Cc: minchan, ngupta, sergey.senozhatsky.work, axboe, linux-kernel,
	linux-block

On Wed, Aug 20, 2025 at 4:44 PM 牛海程 <2023302111378@whu.edu.cn> wrote:
>
> Dear Linux Kernel Zram Maintainers,
>
> I am an open-source developer and have been working on some potential improvements to the Zram module, focusing on optimizing compression rates.My work is based on the Linux kernel version 5.10.240.
>
> My recent work introduces the following changes:
>
> 1.PID and Virtual Address Tracking: During page swap-in operations at the swap layer, I've implemented a mechanism to record the Process ID (PID) and the corresponding virtual address of the page.
> 2.PID-aware Grouping and VMA Merging in Zram: Within the Zram layer, pages are now grouped based on their recorded PIDs. Following this grouping, pages with similar or contiguous virtual addresses within each PID group are merged before compression. The rationale behind this is that pages belonging to the same process and located adjacently in virtual memory are likely to contain related data, which could lead to better compression ratios when processed together.

This seems unnecessarily complex. How does it differ from the mTHP-based
compression we’ve been experimenting with?

https://lore.kernel.org/linux-mm/20241121222521.83458-1-21cnbao@gmail.com/

In that case, you don't need PID-aware or VMA merging etc.

>
> Preliminary experiments using this approach have shown promising results:
>
> With the LZ4 compression algorithm, we observed an approximate 3% increase in the overall compression rate.
> With the ZSTD compression algorithm, the improvement was even more significant, reaching an approximate 4% increase in the overall compression rate.
>
> I am writing to inquire if you believe this approach and its observed benefits are significant enough to warrant further consideration for upstreaming into the main Linux kernel. I would greatly appreciate your thoughts on the utility and potential implications of these changes, as well as any guidance on how to proceed with further development or formal submission.
>
> Thank you for your time and consideration.
> Best regards,
> Haicheng Niu

Thanks
Barry

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH/RFC] Zram: Improved Compression with PID/VMA-aware Grouping
  2025-08-19 11:43 [PATCH/RFC] Zram: Improved Compression with PID/VMA-aware Grouping 牛海程
  2025-08-20  8:49 ` Barry Song
@ 2025-08-21  3:11 ` Sergey Senozhatsky
  1 sibling, 0 replies; 3+ messages in thread
From: Sergey Senozhatsky @ 2025-08-21  3:11 UTC (permalink / raw)
  To: 牛海程
  Cc: minchan, ngupta, senozhatsky, axboe, linux-kernel, linux-block

On (25/08/19 19:43), 牛海程 wrote:
> My recent work introduces the following changes:
> 
> 1.PID and Virtual Address Tracking: During page swap-in
> operations at the swap layer, I've implemented a mechanism
> to record the Process ID (PID) and the corresponding virtual
> address of the page.

Just curious, how did you do that?

Otherwise, I agree with Barry, this looks sort of very complex.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2025-08-21  3:11 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-08-19 11:43 [PATCH/RFC] Zram: Improved Compression with PID/VMA-aware Grouping 牛海程
2025-08-20  8:49 ` Barry Song
2025-08-21  3:11 ` Sergey Senozhatsky

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).