From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 73A681E1A39 for ; Mon, 20 Jan 2025 13:38:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737380286; cv=none; b=cjjoUCibYpDSjIJSKlmRD/xA1p5bkBGEUE1t/nZDNOjWJnVE1j1FBwP4vyxhw0bozSNomcm0p/h0AsbUL3ONJA5XzV6Zdl3D5VZBWOd0o//ZbY8osxF0+Ae6UeM6e1M69xQV5wUmGiDCxowzyuiqSAbe4MYS0iuNYzVIW+GKAeE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737380286; c=relaxed/simple; bh=lKa71HvbcjKwLgpuyYtgdGWtlKm0Kk2k163Py/ysk1s=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=gqUW6ArEIP8teWJB8SMCD5Refq074CgY7F9mjih2zl+f/xZNJ1G5u4NCPX0KhrWIuZNZzg6xnYLIaYzAuC7TuRK3/z0KQTZOlvLxadan/5mxZSE7+Tb2CIKbiTMBq+boxRWloDbQ6xk4GKBFq11IASOeETsxSia4tLj3yVNMs4M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1D02E1063; Mon, 20 Jan 2025 05:38:32 -0800 (PST) Received: from [10.57.80.131] (unknown [10.57.80.131]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8A2DB3F740; Mon, 20 Jan 2025 05:37:58 -0800 (PST) Message-ID: <0a318ea8-7836-405a-a033-f073efdc958f@arm.com> Date: Mon, 20 Jan 2025 13:37:57 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC 00/11] khugepaged: mTHP support Content-Language: en-GB To: David Hildenbrand , Nico Pache Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, anshuman.khandual@arm.com, catalin.marinas@arm.com, cl@gentwo.org, vbabka@suse.cz, mhocko@suse.com, apopple@nvidia.com, dave.hansen@linux.intel.com, will@kernel.org, baohua@kernel.org, jack@suse.cz, srivatsa@csail.mit.edu, haowenchao22@gmail.com, hughd@google.com, aneesh.kumar@kernel.org, yang@os.amperecomputing.com, peterx@redhat.com, ioworker0@gmail.com, wangkefeng.wang@huawei.com, ziy@nvidia.com, jglisse@google.com, surenb@google.com, vishal.moola@gmail.com, zokeefe@google.com, zhengqi.arch@bytedance.com, jhubbard@nvidia.com, 21cnbao@gmail.com, willy@infradead.org, kirill.shutemov@linux.intel.com, aarcange@redhat.com, raquini@redhat.com, dev.jain@arm.com, sunnanyong@huawei.com, usamaarif642@gmail.com, audra@redhat.com, akpm@linux-foundation.org References: <20250108233128.14484-1-npache@redhat.com> <40a65c5e-af98-45f9-a254-7e054b44dc95@arm.com> <37375ace-5601-4d6c-9dac-d1c8268698e9@redhat.com> From: Ryan Roberts In-Reply-To: <37375ace-5601-4d6c-9dac-d1c8268698e9@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 20/01/2025 12:54, David Hildenbrand wrote: >>> I think the 1 problem that emerged during review of Dev's series, which we don't >>> have a proper solution to yet, is the issue of "creep", where regions can be >>> collapsed to progressively higher orders through iterative scans. At each >>> collapse, the required thresholds (e.g. max_ptes_none) are met, and the collapse >>> effectively adds more non-none ptes so the next scan will then collapse to even >>> higher order. Does your solution suffer from this (theoretical/edge case) issue? >>> If not, how did you solve? >> >> Yes sadly it suffers from the same issue. bringing max_ptes_none much >> lower as a default would "help". > > Can we just keep it simple and only support max_ptes_none = 511 ("pagefault > behavior" -- PMD_NR_PAGES - 1) or max_ptes_none = 0 ("deferred behavior") and > document that the other weird configurations will make mTHP skip, because "weird > and unexpetced" ? :) > That sounds like a great simplification in principle! We would need to consider the swap and shared tunables too though. Perhaps we can pull a similar trick with those?