mbox series

[RESEND,0/3] mm/zsmalloc: some cleanup for get/set_zspage_mapping()

Message ID 20240220-b4-zsmalloc-cleanup-v1-0-b7e9cbab9541@linux.dev
Headers
Series mm/zsmalloc: some cleanup for get/set_zspage_mapping() |

Message

Chengming Zhou Feb. 20, 2024, 11:44 a.m. UTC 
  RESEND:
- The sent patches were put into spam folder because of my mail problem,
  so resend after I fixed it, sorry! It should be ok this time.
- Link to v1: https://lore.kernel.org/r/20240220-b4-zsmalloc-cleanup-v1-0-5c5ee4ccdd87@bytedance.com

Hello,

The discussion[1] with Sergey shows there are some cleanup works to do
in get/set_zspage_mapping():

- the fullness returned from get_zspage_mapping() is not stable outside
  pool->lock, this usage pattern is confusing, but should be ok in this
  free_zspage path.

- we seldom use the class_idx returned from get_zspage_mapping(), only
  free_zspage path use to get its class.

- set_zspage_mapping() always set the zspage->class, but it's never
  changed after zspage allocated.

Thanks for review and comments!

[1] https://lore.kernel.org/all/a6c22e30-cf10-4122-91bc-ceb9fb57a5d6@bytedance.com/

Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com>
---
Chengming Zhou (3):
      mm/zsmalloc: remove set_zspage_mapping()
      mm/zsmalloc: remove_zspage() don't need fullness parameter
      mm/zsmalloc: remove get_zspage_mapping()

 mm/zsmalloc.c | 55 +++++++++++++------------------------------------------
 1 file changed, 13 insertions(+), 42 deletions(-)
---
base-commit: 207636f0f52428f3b46540b212d6f93c6ac484cf
change-id: 20240220-b4-zsmalloc-cleanup-560a4159bb6b

Best regards,

Comments

Sergey Senozhatsky Feb. 23, 2024, 5:47 a.m. UTC | #1 
On (24/02/20 11:44), Chengming Zhou wrote:
> From: Chengming Zhou <zhouchengming@bytedance.com>
> 
> We must remove_zspage() from its current fullness list, then use
> insert_zspage() to update its fullness and insert to new fullness list.
> Obviously, remove_zspage() doesn't need the fullness parameter.
> 
> Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com>

Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>