From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-188.mta0.migadu.com (out-188.mta0.migadu.com [91.218.175.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B127F3093DF for ; Sat, 14 Feb 2026 06:35:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.188 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771050919; cv=none; b=oK17uh5FnL1oY30qIoNQOZKRXSrK+bslcWY/IAQgM/Knsr/IKxgAWU5kpEFNTHRucA3B/RXrSpEB5q11Q7RqA8ibWPoREcPxVZ39w7CHB/s0kiInVendN5XzOE/4lIYM4PFsSgEswE2W0MOcxKAfDWw54WYWbZDuFoQJZjOWYaE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771050919; c=relaxed/simple; bh=k+oqdCcjM6C1Amrnu2ScczW0dTvgfSks8DOwZOHeBz8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=YHC+Pk9Sm22+UYl7wTfJST7KE+Z+DsTQI3KlAVn6gOQnOlvui4DxwpIcCysAoA6lwSR6vhSwHgHQ7MWJ46xd2L0yjgCMicMGW700XF0npk9Qd9JCENy2XONKbASRWYPTXyge36LSCCBsHJyW8sXyuLkV5ew8quO9J8+wbL7MoiM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=wCHWPAAe; arc=none smtp.client-ip=91.218.175.188 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="wCHWPAAe" Message-ID: <56345542-544a-48e4-b127-49a850deee9b@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1771050914; h=from:from: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; bh=SKcvyZ0wxQfKnUpcoKe3Juz1omn/zpds7qlJdAAqUDE=; b=wCHWPAAeJLueKrJJjj1gupo7JxSpq0H/0b7y0jlFgVM1uyCl+v4jKzXBQtxlCJASfutFMh Tx25hGPe4JWBmOzzhow0aXhGtv50gW+rZPbj2jTIB8ZXo26jUTM3LdrYWkAVDu8I+9uJBu 3ZmeGB2MxxwqTpyQ6W5nlneL4DGqy5c= Date: Sat, 14 Feb 2026 14:35:07 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCHv2] mm: khugepaged: make scan loops suspend aware To: "David Hildenbrand (Arm)" , Sergey Senozhatsky Cc: Andrew Morton , Lorenzo Stoakes , Zi Yan , Baolin Wang , "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260211031512.261127-1-senozhatsky@chromium.org> <104bc764-5a20-4ac2-95a8-b31f41255766@kernel.org> <3571cf8b-9fb3-41b2-a402-a8537ee2c399@kernel.org> <16ce9ce2-8081-482c-a6ea-0932ebd081f1@kernel.org> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Lance Yang In-Reply-To: <16ce9ce2-8081-482c-a6ea-0932ebd081f1@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 2026/2/12 17:10, David Hildenbrand (Arm) wrote: > On 2/12/26 10:05, Sergey Senozhatsky wrote: >> On (26/02/12 09:44), David Hildenbrand (Arm) wrote: >> [..] >>> If we're fixing an issue, we usually try to identify which commit >>> introduced the >>> issue. >>> >>> For example, support for freezing was introduced in >>> >>> commit 878aee7d6b5504e01b9caffce080e792b6b8d090 >>> Author: Andrea Arcangeli >>> Date:   Thu Jan 13 15:47:10 2011 -0800 >>> >>>      thp: freeze khugepaged and ksmd >>>      It's unclear why schedule friendly kernel threads can't be taken >>> away by >>>      the CPU through the scheduler itself.  It's safer to stop them >>> as they can >>>      trigger memory allocation, if kswapd also freezes itself to avoid >>>      generating I/O they have too. >>> >>> >>> >>> Now that I am looking through the history, I find: >>> >>> commit b39ca208403c8f2c17dab1fbfef1f5ecaff25e53 >>> Author: Kevin Hao >>> Date:   Wed Dec 20 07:17:53 2023 +0800 >>> >>>      mm/khugepaged: remove redundant try_to_freeze() >>>      A freezable kernel thread can enter frozen state during freezing >>> by either >>>      calling try_to_freeze() or using wait_event_freezable() and its >>> variants. >>>      However, there is no need to use both methods simultaneously.  The >>>      freezable wait variants have been used in khugepaged_wait_work() >>> and >>>      khugepaged_alloc_sleep(), so remove this redundant try_to_freeze(). >>>      I used the following stress-ng command to generate some memory >>> load on my >>>      Intel Alder Lake board (24 CPUs, 32G memory). >>> >>> >>> I wonder if that made the issue more likely to appear? >>> >>> >>> Interestingly, we also had in the past: >>> >>> commit 1dfb059b9438633b0546c5431538a47f6ed99028 >>> Author: Andrea Arcangeli >>> Date:   Thu Dec 8 14:33:57 2011 -0800 >>> >>>      thp: reduce khugepaged freezing latency >>>      khugepaged can sometimes cause suspend to fail, requiring that >>> the user >>>      retry the suspend operation. >>> >>> >>> So it's a recurring theme. >> >> Interesting, so 1dfb059b9438633 and 878aee7d6b5504e fixed real >> problems "khugepaged can sometimes cause suspend to fail", but >> I don't see what exactly b39ca208403c8f2 fixed.  Sounds more >> like an "optimization"? > > Yes, a cleanup. I wonder if it caused harm. > >> >>> Given that we only scan "khugepaged_pages_to_scan" pages/ptes/etc. >>> before going back to sleep, >>> I wonder how that can take in your setup that long. >>> >>> Why does it end up taking something around 20 seconds in your setup? >> >> I only have bug reports at hands, I don't have a repro.  Can the fact >> that swap reads require S/W decompression (zram) add enough latency? > > I guess so. 20 seconds is still a lot. > >> >>> How is khugepaged_pages_to_scan set in your environment? >> >> Let me check. >> >> cat /sys/kernel/mm/transparent_hugepage/khugepaged/pages_to_scan >> 4096 >> >> Hmm, doesn't sound too high.  Let me look more. > > Yeah, that's not a lot of pages to scan. It's the default (8 * > HPAGE_PMD_NR) Right. 4096 pages is not much to scan :) This patch lets khugepaged be frozen between VMAs. But if khugepaged is already collapsing when freeze starts, there are two places without freeze checks that could take a bit long: - __collapse_huge_page_swapin() loops 512 pages, calls do_swap_page() for each swap entry. - collapse_file() loops 512 pages, calls shmem_get_folio(). If pages are swapped out, shmem_swapin_folio() is called. Each swap-in can block for I/O. With multiple pages swapped out, the cumulative time adds up. Maybe we also need check points inside these loops to bail out early? Cheers, Lance