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 2544518872D for ; Wed, 18 Dec 2024 09:03:52 +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=1734512635; cv=none; b=gLUoNrmIuB4HVVJydIymtGmJ/MIVTOkUzDGrZku7BZL/rLGY8+QTrGRij9BPd9on77lHnVE0m844V5cDlL1MuApgbvJaOqXUCvhSdEYpFtJoek/nr9np6WCqkMs58nM5ryRv9FjJ7rwHX+zQ4M9I7Y2Dtqqu8cCcoNk0jmMtcjY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734512635; c=relaxed/simple; bh=10Mh/X2I6Jg12rg/i47UVLgvbFq6H53mm0iIxU7+4CY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=aX2/NpsYUMNJoAXd/6j/yfnAX5ixa04As/ZDah5etJ9viW8G1v51CvKMncCaHOAdajp7eruq4YoBieYu324nMO3rAj/U4s7XGP0vE5BY4fomHH06NfGwWQTfUPwPBW/XTx15wSVDqdlztYsGiLuXJ01aJ7rC0D4+0/t8JGpioDU= 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 5C233FEC; Wed, 18 Dec 2024 01:04:20 -0800 (PST) Received: from [10.57.91.184] (unknown [10.57.91.184]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0FF2B3F7B4; Wed, 18 Dec 2024 01:03:46 -0800 (PST) Message-ID: <7098654a-776d-413b-8aca-28f811620df7@arm.com> Date: Wed, 18 Dec 2024 09:03:45 +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 PATCH 12/12] selftests/mm: khugepaged: Enlighten for mTHP collapse Content-Language: en-GB To: Dev Jain , akpm@linux-foundation.org, david@redhat.com, willy@infradead.org, kirill.shutemov@linux.intel.com Cc: 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, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20241216165105.56185-1-dev.jain@arm.com> <20241216165105.56185-13-dev.jain@arm.com> From: Ryan Roberts In-Reply-To: <20241216165105.56185-13-dev.jain@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 16/12/2024 16:51, Dev Jain wrote: > One of the testcases triggers a CoW on the 255th page (0-indexing) with > max_ptes_shared = 256. This leads to 0-254 pages (255 in number) being unshared, > and 257 pages shared, exceeding the constraint. Suppose we run the test as > ./khugepaged -s 2. Therefore, khugepaged starts collapsing the range to order-2 > folios, since PMD-collapse will fail due to the constraint. > When the scan reaches 254-257 PTE range, because at least one PTE in this range > is writable, with other 3 being read-only, khugepaged collapses this into an > order-2 mTHP, resulting in 3 extra PTEs getting unshared. After this, we encounter > a 4-sized chunk of read-only PTEs, and mTHP collapse stops according to the scaled > constraint, but the number of shared PTEs have now come under the constraint for > PMD-sized THPs. Therefore, the next scan of khugepaged will be able to collapse > this range into a PMD-mapped hugepage, leading to failure of this subtest. Fix > this by reducing the CoW range. Is this description essentially saying that it's now possible to creep towards collapsing to a full PMD-size block over successive scans due to rounding errors in the scaling? Or is this just trying an edge case and the problem doesn't generalize? > > Note: The only objective of this patch is to make the test work for the PMD-case; > no extension has been made for testing for mTHPs. > > Signed-off-by: Dev Jain > --- > tools/testing/selftests/mm/khugepaged.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/tools/testing/selftests/mm/khugepaged.c b/tools/testing/selftests/mm/khugepaged.c > index 8a4d34cce36b..143c4ad9f6a1 100644 > --- a/tools/testing/selftests/mm/khugepaged.c > +++ b/tools/testing/selftests/mm/khugepaged.c > @@ -981,6 +981,7 @@ static void collapse_fork_compound(struct collapse_context *c, struct mem_ops *o > static void collapse_max_ptes_shared(struct collapse_context *c, struct mem_ops *ops) > { > int max_ptes_shared = thp_read_num("khugepaged/max_ptes_shared"); > + int fault_nr_pages = is_anon(ops) ? 1 << anon_order : 1; > int wstatus; > void *p; > > @@ -997,8 +998,8 @@ static void collapse_max_ptes_shared(struct collapse_context *c, struct mem_ops > fail("Fail"); > > printf("Trigger CoW on page %d of %d...", > - hpage_pmd_nr - max_ptes_shared - 1, hpage_pmd_nr); > - ops->fault(p, 0, (hpage_pmd_nr - max_ptes_shared - 1) * page_size); > + hpage_pmd_nr - max_ptes_shared - fault_nr_pages, hpage_pmd_nr); > + ops->fault(p, 0, (hpage_pmd_nr - max_ptes_shared - fault_nr_pages) * page_size); > if (ops->check_huge(p, 0)) > success("OK"); > else