From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F14B0C3ABBC for ; Wed, 7 May 2025 02:04:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 67F0F6B0083; Tue, 6 May 2025 22:04:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 605BD6B0085; Tue, 6 May 2025 22:04:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 459C96B0088; Tue, 6 May 2025 22:04:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 1F1976B0083 for ; Tue, 6 May 2025 22:04:51 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id CCCDFC0AAC for ; Wed, 7 May 2025 02:04:51 +0000 (UTC) X-FDA: 83414468382.17.9E24472 Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) by imf21.hostedemail.com (Postfix) with ESMTP id E30B11C000A for ; Wed, 7 May 2025 02:04:49 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LVh0Ofnb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.210.52 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746583489; a=rsa-sha256; cv=none; b=ouWPIOoUMHNo/J8RRc06fujT7q/koV/DLbI7CpQKFLAfPs5htlWzWW96tocgz0ugZ7yQla Di0WuMarzeumhpKi5AByq2klAGJEi9iDp/dyPDKIWeHlDvP0HremPYhOvPaz+x4J2vKBnO /2mBG6R1M3Fy7t0lIYQ+DTTnmoRkUrI= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LVh0Ofnb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.210.52 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746583489; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=NlPsxC11d3qugk3PiiF8rZ2ohueNrS2+jnyIkxmqeRI=; b=FHgPyIhdzm4YBJWya474L1PQuWA+/2X+0EOj+q4CPxK74ox8WA3V5V4M+vDhgeOpphk18R 4hmU1tixAFD61w6KTCfH2UbusqzaGGDEHfHobtuThH6vMpsHlMXRYo0Hya22ILElloAV01 32mVHSsMCmJ9e1x6/7dmpZ6AsyrQzfQ= Received: by mail-ot1-f52.google.com with SMTP id 46e09a7af769-72ecc30903cso3303523a34.0 for ; Tue, 06 May 2025 19:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746583489; x=1747188289; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=NlPsxC11d3qugk3PiiF8rZ2ohueNrS2+jnyIkxmqeRI=; b=LVh0Ofnbo+PsP92r6qxu371XNP4V1pg3ZJ0qyGqaGitxsij38jboDk0Dp0EyIqSDvA b1E7JP404+Ap0hfUhhFKXkA7dXRK3UipAcx83al/tl8F2BoNIdP6z/i/aqJfDgwuI/MX 1mE5yjqb7n2c566kuOSq3HGhyQPU/wnZeKiV9glSXUTG3PvSbZUyvffzix/CMzpTWPMn BhepFHX6AJyh15yrVLDyjeEYRbdKv3m0u5zvv+gUwHWi4ZWmzcH6kqe9Ez6rigZW9/9a jMTCGmmYOYc7/+amVOefr8Eaao93oDYcCnU6YibJezgPC7b2jt76wzmNs3+NWJQQlqc3 hI+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746583489; x=1747188289; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NlPsxC11d3qugk3PiiF8rZ2ohueNrS2+jnyIkxmqeRI=; b=mZHjgjvXU/BT7xqiFDANoTbmW57Ktx0vWMsgE6LC0JuARYClz6eMtlR9BtryZ2EbDs LpMS3N7QNBODEHVnuinQcVfH9JRm5qWStEj+4zWqypw9QhBYOmvZ8LsHcAWekDEwYQVN xrNKRZKnL1EARoQqNEnYx3Fg8Zxigb45t/ul8IhxMQuSRzT0+ijnPk+sFosvf7kxTjx+ Ig3mq0TZaaRnxVxYMbx/ycdcwG4yTrEc0s1AeYLk3DZnLiPn7krrzmGZar9/h/6Xs6Fk OvAW9qWzoL3iWFYtMaQtDcTrWROvXDLiol4unOt9fTlv9sIRXlAZGccKmYR+6No/ea9I FKPg== X-Forwarded-Encrypted: i=1; AJvYcCWsa5KHg3Li+v9q5vXiSOpCfbYDeClbL6Zy1+LmBcsdVnahPv59yNFB2rkdd58o2uuUlMcsY2UIdA==@kvack.org X-Gm-Message-State: AOJu0Yzz401Lp9epLU6X7GwbEdZzRQBCkwYLZqUEnsdcrxjzj2G4rzC5 k7dwz5H1o9uz2bMk0mRocxmRByFJtVCzj2+TVEI80UKg+7KWUmAWXQ4TePp1HVMMldoIkC6B8GS xfmQhdaP+Hf0OXm5xNR5iudUaWGBlQ+OE X-Gm-Gg: ASbGnctYuCZ4EKogg22A7aqYvJGJwTAIBZxBgAxsKdAfCChT5mN36iHscZaEtWUgX3Z 39Ab5IxgTzI7CaktyAOjkwUAi0XPt0KMc+ZlLdQwcUSeWuazAkVCmHbWxYRfXJDJcBWBJ91W/0v mFVyxySr1goJYEmtOGi6ROYtHvlnyogss6 X-Google-Smtp-Source: AGHT+IHkoHMO0xYsvp350pbjoRMWgdZnVLWKkLvedDtfBTCi2Y6k7q50Oi7/B2wFj1uQ0BoUIWUzH6GiKF5JtinND5o= X-Received: by 2002:a05:6122:551:b0:520:6773:e5ba with SMTP id 71dfb90a1353d-52c379a3dc6mr1479504e0c.2.1746583477798; Tue, 06 May 2025 19:04:37 -0700 (PDT) MIME-Version: 1.0 References: <20250430082651.3152444-1-qun-wei.lin@mediatek.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Wed, 7 May 2025 14:04:26 +1200 X-Gm-Features: ATxdqUH1oP4gvc5AhGcGTGALh-RMubLjfFrIFKil_cBMYlEf1IwwAvlRK2V8GAc Message-ID: Subject: Re: [PATCH] mm: Add Kcompressd for accelerated memory compression To: Zi Yan Cc: Harry Yoo , Qun-Wei Lin , Andrew Morton , Mike Rapoport , Matthias Brugger , AngeloGioacchino Del Regno , Nhat Pham , Sergey Senozhatsky , Minchan Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Casper Li , Chinwen Chang , Andrew Yang , James Hsu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: E30B11C000A X-Stat-Signature: 4gsna555s7y3mru84jkc6aknfmbq3wnm X-HE-Tag: 1746583489-493340 X-HE-Meta: U2FsdGVkX18v5MH+ubRm5NSrak2WR+V2h4SUjK/6c/PkwZsHhwa6QXASjkwI48r93lZYMh/1RD6rhdDje2WqO3IT78tWrlk5SH7ajvXZKBWHu1Gb5W1PDgx8lQG51+o6P0EmJ8dC4qXy43IvsWNZ2QfcnoocHCAK2elq9RSHlgtPDIFEWoCSgsZcESFy7b8G3objQHm+guCLPUAbHMrumdf1HjVNtwm3Ebj+/D0zra2N4n3aggdDDZuqzBFrwfPzwUdTIOV0t4eHWm1KcBQ2ncLG0zPKGuG+gEziMIOgp40OaFPmji0JGffHzWWkuUvOU7ymh2qo330bj0qPXqagf8oIX7/VHbD3ipcqya+MI2hr3up/KFoVv9FhccmO3MXgVypBE3LNEWQf+/YtBrARcsAgbAndoFFyG0cM43tGNkm9VJ4rWsDQnU+eBGMATmXQYXJfqsfILelx8kxnA2/Urtz447s0twV+Sjer0So8eunoWQDt/sCTjlwjbcIBKWoksxpurjXqSFcm3yK8D83Jiz0Utymf/GlO7HTxlzQciieINaFESvJwDL2APFhz1JujTCLPaNqnCgMRBx8x8lMmBd1HXdBxMIher+QXbHBimv69h4pzxJU7qHg/3f+6RwUeWOaqdbU/y7NMyQYZGEZspr5gE5tOY0OusAD6dXliSebCgT8v8ZWuVl8h6eqZeddWryIp5rX0Y2iArr1fpXnmEX/W1OcQHYzpybL6wPXQEA7pYWB5VclUib3CeqI9Bq9vyTofr8U8S/C02OH+NQztI0FRRxKp4DOTCa/soAJZsaBGioNoVoTpopuh9s+wlkDJm4GRINIt9VOSx2/Q0iexZrh55FrIXr6bb4h8d7pvQ8VONdpEYs8lKDwLHBmp3vDdw/yDea1fWgY/oUFKjHFHHVpF0rvp3f2klEeWE5/0fn656fVIWmzwleZPUtM6Zup264bdlf+AvFxpjwUs5ES 2vUQAkJq XLS2pOx+P5cyvyHwU/8Uyheou1f9maIy90Lmb3bw8LR+gffq2LuVjWw7peOTPLQ4zMLihJo2shKx1x0mJ2EH7yQ0lYXwOAEYPj1UEVvE/3RompPg1IYCktw4sxQm39ro46aHc//nHgK1086P47mUMOYzD/kZco6ifR5WNEOCFDGlgX9uKECpFMzLTea7H7swLNk5UfHJDirnaAXAEgeQPKqShjHomrVnybHtbqQIGZcqFuTWsHzkEZ9pErFDpwnl+TO+qaWPc1Ydyw1PjsgHBzjYXJpLk5AuA6ZGhACOEq7Vsa88uy9DxTtG+UgzDZBwC/Z8pOcZ79/NCTI1D7QZXeucyahueGVjxZSqAmzVnwhJ+tPqFz/NQsAOeBezPB9IwliolX9wmZZzakRtiznVAMCInHB0E9/k9LV9yNL4+1D9fJeXRBDxM7/VO/OxSTjk8MF8IUozJXHBuIJb/jbGwdpQ3yvm8JdeTShnYOgeAgTWLeptYAce2DNWgqL59kUALbez32a2HpwMbQI4TVSwLfRkj4g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, May 7, 2025 at 1:50=E2=80=AFPM Zi Yan wrote: > > On 6 May 2025, at 21:12, Harry Yoo wrote: > > > On Wed, Apr 30, 2025 at 04:26:41PM +0800, Qun-Wei Lin wrote: > >> This patch series introduces a new mechanism called kcompressd to > >> improve the efficiency of memory reclaiming in the operating system. > >> > >> Problem: > >> In the current system, the kswapd thread is responsible for both sca= nning > >> the LRU pages and handling memory compression tasks (such as those > >> involving ZSWAP/ZRAM, if enabled). This combined responsibility can = lead > >> to significant performance bottlenecks, especially under high memory > >> pressure. The kswapd thread becomes a single point of contention, ca= using > >> delays in memory reclaiming and overall system performance degradati= on. > >> > >> Solution: > >> Introduced kcompressd to handle asynchronous compression during memo= ry > >> reclaim, improving efficiency by offloading compression tasks from > >> kswapd. This allows kswapd to focus on its primary task of page recl= aim > >> without being burdened by the additional overhead of compression. > >> > >> In our handheld devices, we found that applying this mechanism under h= igh > >> memory pressure scenarios can increase the rate of pgsteal_anon per se= cond > >> by over 260% compared to the situation with only kswapd. Additionally,= we > >> observed a reduction of over 50% in page allocation stall occurrences, > >> further demonstrating the effectiveness of kcompressd in alleviating m= emory > >> pressure and improving system responsiveness. > >> > >> Co-developed-by: Barry Song <21cnbao@gmail.com> > >> Signed-off-by: Barry Song <21cnbao@gmail.com> > >> Signed-off-by: Qun-Wei Lin > >> Reference: Re: [PATCH 0/2] Improve Zram by separating compression cont= ext from kswapd - Barry Song > >> https://lore.kernel.org/lkml/20250313093005.13998-1-21cnbao@= gmail.com/ > >> --- > > > > +Cc Zi Yan, who might be interested in writing a framework (or improvin= g > > the existing one, padata) for parallelizing jobs (e.g. migration/compre= ssion) > > Thanks. > > I am currently looking into padata [1] to perform multithreaded page migr= ation > copy job. But based on this patch, it seems that kcompressed is just an a= dditional > kernel thread of executing zswap_store(). Is there any need for performin= g > compression with multiple threads? The current focus is on enabling kswapd to perform asynchronous compression= , which can significantly reduce direct reclaim and allocstall events. Therefore, the work begins with supporting a single thread. Supporting multiple threads might be possible in the future, but it could be difficult to control=E2=80=94especially on busy phones=E2=80=94since it consumes more= power and may interfere with other threads impacting user experience. > > BTW, I also notice that zswap IAA compress batching patchset[2] is using > hardware accelerator (Intel Analytics Accelerator) to speed up zswap. > I wonder if the handheld devices have similar hardware to get a similar b= enefit. Usually, the answer is no. We use zRAM and CPU, but this patch aims to prov= ide a common capability that can be shared by both zRAM and zswap. > > > [1] https://docs.kernel.org/core-api/padata.html > [2] https://lore.kernel.org/linux-crypto/20250303084724.6490-1-kanchana.p= .sridhar@intel.com/ > > > >> include/linux/mmzone.h | 6 ++++ > >> mm/mm_init.c | 1 + > >> mm/page_io.c | 71 +++++++++++++++++++++++++++++++++++++++++= + > >> mm/swap.h | 6 ++++ > >> mm/vmscan.c | 25 +++++++++++++++ > >> 5 files changed, 109 insertions(+) > >> > >> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > >> index 6ccec1bf2896..93c9195a54ae 100644 > >> --- a/include/linux/mmzone.h > >> +++ b/include/linux/mmzone.h > >> @@ -23,6 +23,7 @@ > >> #include > >> #include > >> #include > >> +#include > >> #include > >> > >> /* Free memory management - zoned buddy allocator. */ > >> @@ -1398,6 +1399,11 @@ typedef struct pglist_data { > >> > >> int kswapd_failures; /* Number of 'reclaimed =3D=3D 0'= runs */ > >> > >> +#define KCOMPRESS_FIFO_SIZE 256 > >> + wait_queue_head_t kcompressd_wait; > >> + struct task_struct *kcompressd; > >> + struct kfifo kcompress_fifo; > >> + > >> #ifdef CONFIG_COMPACTION > >> int kcompactd_max_order; > >> enum zone_type kcompactd_highest_zoneidx; > >> diff --git a/mm/mm_init.c b/mm/mm_init.c > >> index 9659689b8ace..49bae1dd4584 100644 > >> --- a/mm/mm_init.c > >> +++ b/mm/mm_init.c > >> @@ -1410,6 +1410,7 @@ static void __meminit pgdat_init_internals(struc= t pglist_data *pgdat) > >> pgdat_init_kcompactd(pgdat); > >> > >> init_waitqueue_head(&pgdat->kswapd_wait); > >> + init_waitqueue_head(&pgdat->kcompressd_wait); > >> init_waitqueue_head(&pgdat->pfmemalloc_wait); > >> > >> for (i =3D 0; i < NR_VMSCAN_THROTTLE; i++) > >> diff --git a/mm/page_io.c b/mm/page_io.c > >> index 4bce19df557b..d85deb494a6a 100644 > >> --- a/mm/page_io.c > >> +++ b/mm/page_io.c > >> @@ -233,6 +233,38 @@ static void swap_zeromap_folio_clear(struct folio= *folio) > >> } > >> } > >> > >> +static bool swap_sched_async_compress(struct folio *folio) > >> +{ > >> + struct swap_info_struct *sis =3D swp_swap_info(folio->swap); > >> + int nid =3D numa_node_id(); > >> + pg_data_t *pgdat =3D NODE_DATA(nid); > >> + > >> + if (unlikely(!pgdat->kcompressd)) > >> + return false; > >> + > >> + if (!current_is_kswapd()) > >> + return false; > >> + > >> + if (!folio_test_anon(folio)) > >> + return false; > >> + /* > >> + * This case needs to synchronously return AOP_WRITEPAGE_ACTIVATE > >> + */ > >> + if (!mem_cgroup_zswap_writeback_enabled(folio_memcg(folio))) > >> + return false; > >> + > >> + sis =3D swp_swap_info(folio->swap); > >> + if (zswap_is_enabled() || data_race(sis->flags & SWP_SYNCHRONOUS_= IO)) { > >> + if (kfifo_avail(&pgdat->kcompress_fifo) >=3D sizeof(folio= ) && > >> + kfifo_in(&pgdat->kcompress_fifo, &folio, sizeof(f= olio))) { > >> + wake_up_interruptible(&pgdat->kcompressd_wait); > >> + return true; > >> + } > >> + } > >> + > >> + return false; > >> +} > >> + > >> /* > >> * We may have stale swap cache pages in memory: notice > >> * them here and get rid of the unnecessary final write. > >> @@ -275,6 +307,15 @@ int swap_writepage(struct page *page, struct writ= eback_control *wbc) > >> */ > >> swap_zeromap_folio_clear(folio); > >> } > >> + > >> + /* > >> + * Compression within zswap and zram might block rmap, unmap > >> + * of both file and anon pages, try to do compression async > >> + * if possible > >> + */ > >> + if (swap_sched_async_compress(folio)) > >> + return 0; > >> + > >> if (zswap_store(folio)) { > >> count_mthp_stat(folio_order(folio), MTHP_STAT_ZSWPOUT); > >> folio_unlock(folio); > >> @@ -289,6 +330,36 @@ int swap_writepage(struct page *page, struct writ= eback_control *wbc) > >> return 0; > >> } > >> > >> +int kcompressd(void *p) > >> +{ > >> + pg_data_t *pgdat =3D (pg_data_t *)p; > >> + struct folio *folio; > >> + struct writeback_control wbc =3D { > >> + .sync_mode =3D WB_SYNC_NONE, > >> + .nr_to_write =3D SWAP_CLUSTER_MAX, > >> + .range_start =3D 0, > >> + .range_end =3D LLONG_MAX, > >> + .for_reclaim =3D 1, > >> + }; > >> + > >> + while (!kthread_should_stop()) { > >> + wait_event_interruptible(pgdat->kcompressd_wait, > >> + !kfifo_is_empty(&pgdat->kcompress_fifo)); > >> + > >> + while (!kfifo_is_empty(&pgdat->kcompress_fifo)) { > >> + if (kfifo_out(&pgdat->kcompress_fifo, &folio, siz= eof(folio))) { > >> + if (zswap_store(folio)) { > >> + count_mthp_stat(folio_order(folio= ), MTHP_STAT_ZSWPOUT); > >> + folio_unlock(folio); > >> + continue; > >> + } > >> + __swap_writepage(folio, &wbc); > >> + } > >> + } > >> + } > >> + return 0; > >> +} > >> + > >> static inline void count_swpout_vm_event(struct folio *folio) > >> { > >> #ifdef CONFIG_TRANSPARENT_HUGEPAGE > >> diff --git a/mm/swap.h b/mm/swap.h > >> index 6f4a3f927edb..3579da413dc2 100644 > >> --- a/mm/swap.h > >> +++ b/mm/swap.h > >> @@ -22,6 +22,7 @@ static inline void swap_read_unplug(struct swap_iocb= *plug) > >> void swap_write_unplug(struct swap_iocb *sio); > >> int swap_writepage(struct page *page, struct writeback_control *wbc); > >> void __swap_writepage(struct folio *folio, struct writeback_control *= wbc); > >> +int kcompressd(void *p); > >> > >> /* linux/mm/swap_state.c */ > >> /* One swap address space for each 64M swap space */ > >> @@ -199,6 +200,11 @@ static inline int swap_zeromap_batch(swp_entry_t = entry, int max_nr, > >> return 0; > >> } > >> > >> +static inline int kcompressd(void *p) > >> +{ > >> + return 0; > >> +} > >> + > >> #endif /* CONFIG_SWAP */ > >> > >> #endif /* _MM_SWAP_H */ > >> diff --git a/mm/vmscan.c b/mm/vmscan.c > >> index 3783e45bfc92..2d7b9167bfd6 100644 > >> --- a/mm/vmscan.c > >> +++ b/mm/vmscan.c > >> @@ -7420,6 +7420,7 @@ unsigned long shrink_all_memory(unsigned long nr= _to_reclaim) > >> void __meminit kswapd_run(int nid) > >> { > >> pg_data_t *pgdat =3D NODE_DATA(nid); > >> + int ret; > >> > >> pgdat_kswapd_lock(pgdat); > >> if (!pgdat->kswapd) { > >> @@ -7433,7 +7434,26 @@ void __meminit kswapd_run(int nid) > >> } else { > >> wake_up_process(pgdat->kswapd); > >> } > >> + ret =3D kfifo_alloc(&pgdat->kcompress_fifo, > >> + KCOMPRESS_FIFO_SIZE * sizeof(struct folio= *), > >> + GFP_KERNEL); > >> + if (ret) { > >> + pr_err("%s: fail to kfifo_alloc\n", __func__); > >> + goto out; > >> + } > >> + > >> + pgdat->kcompressd =3D kthread_create_on_node(kcompressd, = pgdat, nid, > >> + "kcompressd%d", nid); > >> + if (IS_ERR(pgdat->kcompressd)) { > >> + pr_err("Failed to start kcompressd on node %d=EF= =BC=8Cret=3D%ld\n", > >> + nid, PTR_ERR(pgdat->kcompressd)); > >> + pgdat->kcompressd =3D NULL; > >> + kfifo_free(&pgdat->kcompress_fifo); > >> + } else { > >> + wake_up_process(pgdat->kcompressd); > >> + } > >> } > >> +out: > >> pgdat_kswapd_unlock(pgdat); > >> } > >> > >> @@ -7452,6 +7472,11 @@ void __meminit kswapd_stop(int nid) > >> kthread_stop(kswapd); > >> pgdat->kswapd =3D NULL; > >> } > >> + if (pgdat->kcompressd) { > >> + kthread_stop(pgdat->kcompressd); > >> + pgdat->kcompressd =3D NULL; > >> + kfifo_free(&pgdat->kcompress_fifo); > >> + } > >> pgdat_kswapd_unlock(pgdat); > >> } > >> > >> -- > >> 2.45.2 > >> > >> > > > > -- > > Cheers, > > Harry / Hyeonggon > > > -- > Best Regards, > Yan, Zi Thanks Barry