From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 797911A316E for ; Sun, 5 Jul 2026 18:50:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783277448; cv=none; b=jLDpeUpX4XyJl77gJ7ivpm2NO9IhNPW6UNaSgkS/Rtj80B0F0rilJR8ioPXMDAzXvIcpeckzOypoNZ5MKQqWSYghEBpQ0kinZhdT5BEyq22Ms8EsW9ivBFD1DoHM6SF0meaExha+Uf6e4IFMfGvrHiBB8t9opB+3njK3C8gJXUY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783277448; c=relaxed/simple; bh=TAPqTnd2B0Qm0PIXabvSEwf2lem7I655mSbiIlEL7ms=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=OHa0A3Ukhkp4GUvHyYhNhEzvsWC6DQfqHFvHVlMxSdWOZR/GsBfOl7RttxXDFEf8E6S9cNCArhqKpm4gLig05yhrFteOZ3x+Az/SxveA0f2NLY0MsjRVtgqSzTDzOZKsSjIkTT8pPxozGjKLr3SCT4CHYxzFCgpn8bUGhsIp9Ik= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=rtHQAfw/; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="rtHQAfw/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 231231F000E9; Sun, 5 Jul 2026 18:50:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1783277447; bh=r8lzWoonUAmF9jSZ3sxb3NCfU6HKSy4ivLDREqGKh2U=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=rtHQAfw/0VYKyWgm77bwW/E8pKkfWsbGSuysL2f+xSBVo5vB1tFlRD3IeFzKqfiJu TxD0jxswIt/S4o37e8IIGVMVlr0C/UbcEoCdiIFvx02c9qYK7f6Mu2tDCS8cFM46/+ oYmEzrTVjyl1jjz5YNO2M1VONKpAk+Rs+YHWQp+E= Date: Sun, 5 Jul 2026 11:50:45 -0700 From: Andrew Morton To: Jiaqi Yan Cc: linmiaohe@huawei.com, ljs@kernel.org, ziy@nvidia.com, vbabka@kernel.org, osalvador@kernel.org, harry.yoo@oracle.com, willy@infradead.org, osalvador@suse.de, jackmanb@google.com, hannes@cmpxchg.org, nao.horiguchi@gmail.com, david@kernel.org, william.roche@oracle.com, tony.luck@intel.com, wangkefeng.wang@huawei.com, jane.chu@oracle.com, muchun.song@linux.dev, liam@infradead.org, rientjes@google.com, duenwen@google.com, jthoughton@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, vbabka@suse.cz, rppt@kernel.org, shuah@kernel.org, surenb@google.com, mhocko@suse.com, boudewijn@delta-utec.com Subject: Re: [PATCH v6 0/5] Only free healthy pages in high-order has_hwpoisoned folio Message-Id: <20260705115045.eba41efda0c46121b1d10827@linux-foundation.org> In-Reply-To: <20260705180714.3708947-1-jiaqiyan@google.com> References: <20260705180714.3708947-1-jiaqiyan@google.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 5 Jul 2026 18:07:09 +0000 Jiaqi Yan wrote: > At the end of dissolve_free_hugetlb_folio(), a free HugeTLB > folio becomes non-HugeTLB and is released to buddy allocator > as a high-order folio, e.g. a folio that contains 262144 pages > if the folio was a 1G HugeTLB hugepage. > > ... > > Introduce free_has_hwpoisoned() to only free the healthy pages > and exclude the HWPoison ones in the high-order folio. > free_has_hwpoisoned() happens at the end of free_pages_prepare(), > which already deals with both decomposing the original compound > page, updating page metadata like alloc tag and page owner. > It is also only applied when PG_has_hwpoisoned indicates folio > contains certain HWPoison page(s) for performance reason. > Its idea is to iterate through the sub-pages of the folio to > identify contiguous ranges of healthy pages. Instead of freeing > pages one by one, free_has_hwpoisoned() then re-use > free_prepared_contig_range() [11] to decompose healthy ranges into > the largest possible chunks of different orders. Every chunk is > freed via __free_frozen_pages(). Thanks. I'll await further reviewer input before taking any action with this series. AI review flags several possible issues, some of them pre-existing: https://sashiko.dev/#/patchset/20260705180714.3708947-1-jiaqiyan@google.com