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 931EFC02188 for ; Tue, 28 Jan 2025 01:07:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F2CD02801F1; Mon, 27 Jan 2025 20:07:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EDBF52801D0; Mon, 27 Jan 2025 20:07:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DAD5F2801F1; Mon, 27 Jan 2025 20:07:58 -0500 (EST) 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 BA5E12801D0 for ; Mon, 27 Jan 2025 20:07:58 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 66F0D1C7F04 for ; Tue, 28 Jan 2025 01:07:58 +0000 (UTC) X-FDA: 83055073836.14.8AE5DCE Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf06.hostedemail.com (Postfix) with ESMTP id BBA7B18000F for ; Tue, 28 Jan 2025 01:07:56 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=jo1guj6p; spf=pass (imf06.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738026476; 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=cij9ol7ZA5h45+F++4PquSXdVx+ZUBJWTbMONDCHjWI=; b=tkaHkrGx2kxg+MpI6b90cR0Ms+IxhxxmBvLBk7LEqyB8ejXzYRyRjvGQbyN+qxVrblwiF9 1NLes4jeQ3EueawlfYTWTABdCVJSe5q6eFOUYyl0tWXdXt/jlrbV3R/+kdQsi64MFbWBRA dfa7x9T2ZHidgrYoflDgmcd87nPEYnE= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=jo1guj6p; spf=pass (imf06.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738026476; a=rsa-sha256; cv=none; b=zPxQPc06dVgl1YXi8bwO00d2u7hX1KS6RWtkH2DndLrVOMX9ey7IQy2vvg5vjFoCTRY0k+ WC9AQwKcPFQQkdTJkbXjWaAFDR3uphZcJnCnEqiLRRVRpxjveUeLWEu4wetCHuvBQvnHyv cGPExEUKSfiz8wEwYPZJ3zc8qBIIOnw= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 0EB3CA41892; Tue, 28 Jan 2025 01:06:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 817E5C4CED2; Tue, 28 Jan 2025 01:07:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1738026475; bh=WRh/SaErv3NSOrjLV96+P/lfswtBw2EKUEWeFOVZFAs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=jo1guj6pDXQKFvRy6RsUdrY6TOWPEyfS+BWCu1PJ8CTtwdBQjVtmYW+krcLWkN8NS 7alKcIShHXhV3iGQ6SPbdkpi+PEmnmpm94wAkMjZGys9JAEh+L+YwxSEyTzMmsIac2 KlnQCuzfs0Tay0Nsn37yLYKVoiqeBBBFxKPtWMKM= Date: Mon, 27 Jan 2025 17:07:54 -0800 From: Andrew Morton To: Michal Clapinski Cc: Vlastimil Babka , Pasha Tatashin , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 0/2] mm/compaction: allow more aggressive proactive compaction Message-Id: <20250127170754.955ecfc1ed3249a027fbebce@linux-foundation.org> In-Reply-To: <20250127215020.4023545-1-mclapinski@google.com> References: <20250127215020.4023545-1-mclapinski@google.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: BBA7B18000F X-Stat-Signature: 1e5shstgkqjyawfkefh87zdo6uyhgp7h X-Rspam-User: X-HE-Tag: 1738026476-45211 X-HE-Meta: U2FsdGVkX18sZhCs4pEcbyFT3w5zRUBw7EBkgrlGNlRiq8cJkGt61m4ozYmAms609bFNmwfN1CM5gYG1nFuuWRaUd/u+X50Ulruaemws67g2h1ane1rXAXNdt++OykY6IyYRWzD2Z8G5HJBhgIh9p+oN6MtjFJ/XDfBjjJj60lmUqC2qMvAGOYLnkCz4zaoTvIeZaBttGONSy1hjJTpIi+yOWoYcWjO/UycJlJaRbLfu6v6LRgl/YYAWDikUmS6TnP+bRA/Sj+WXDzLgQkJp448OU6akojXm8WWEcf8u81SKzPRa9kabkOxRi7Wdy375TxXoxI8xs2V6SzXOZTn/Y913BONrbcAiCUO5618DOYcGJrhSjzFl/JChA91ImWJtAADsByxBJuzqkHZWrJcU7YEVxYRvL1AlPawz9jxoO8jwMfU0iKy2Zs17wSR0gdGs63Y1yLv1bSfpdtXLjc6JvuspDsEMp326t16+X3Io14vi2GLCQa58z01FyW3UP58qYiW+dF5TQArfG55H/Kb+XqVWVuTkIOiIrT7o0S54GMJNG4AEnsLXQK+3aiEQpUe3T6TkaGFWoKkOIjkU16xi2qn5OVf58BqNA0lz06+U12U6Onr/EP90Sj7mxN7lzMq0bBd0PLKP2LZpcnIfawSXVxA74EQC5EPNVAGJAZn3bJg1dHlG6+wEwwbnXZLze2c8md+MM2Hr2Cj4g3wn/ZJcLHjWhHpGHJmHAIMlBu7UEx1tv/sf6nX8j0UAVDS+UR3gM88N3qzPbXsQfyWKhnycOVKHkHvz5GS96bWNzaTgMxHzskYTs1ZNC8zNxVLytEZAMHP2yNjJbKjOXxVV2L0bTInaU9fV6cOFEH3kjt2hcNtlmliSnVPmq2MUvwJVXsOUOwR0p2pBQ1m3zOXVZs3XNy56S9hMiUUS2ABGpnlqqs9w7dzRFKTyOaXYxInBr3esQ3UwxeZS7rWXE39TaeZ Z7HnXjBl Kf6nN7gcgwZ14ulJ/jr+z5McKmxoQQR6qmBJJbTbjreK3x/uwWUwtQtyOVCJ7UUZfW+/dQulPQGGtGmUqwZjlQIZH4MAPqXMPdWujLUnRLxc4j6y5CqnKMCVMEXw6qYlcm3zWcaP4JNElcpEcWNO1uPG/r0VI93xGXIoxTAiTMTLin69iHmGGP8qshpMwmnfKeuoWrhLDbg+ILVV4kNJMHExzABE5BEp5rnbpNDQHQYQ1JjGCjjGapqXvYFh50KIASzNVssl+6RIiWCo= 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 Mon, 27 Jan 2025 22:50:18 +0100 Michal Clapinski wrote: > Our goal is to keep memory usage of a VM low on the host. For that > reason, we use free page reporting which by default reports free pages > of order 9 and larger to the host to be freed. The feature works well > only if the memory in the guest is not fragmented below pages of order > 9. Proactive compaction can be reused to achieve defragmentation after > some parameter tweaking. > > When the fragmentation score (lower is better) gets larger than the > high watermark, proactive compaction kicks in. Compaction stops when > the score goes below the low watermark (or no progress is made and > backoff kicks in). Let's define the difference between high and low > watermarks as leeway. Before these changes, the minimum possible value > for low watermark was 5 and the leeway was hardcoded to 10 (so minimum > possible value for high watermark was 15). > It would be helpful to let us know the benefits of this change for our users. Some reasonably detailed real-world before-and-after narrative would suit, please.