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 E82182B2DA for ; Thu, 11 Dec 2025 15:43:33 +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=1765467815; cv=none; b=nvO5Ca2SJmw+TBnU68OcRR9pQ/yPcjoK3OPmGXHVHNQl6iZKUOKvFS172g4kvwVxnFQx4/sFzfA/Po5SCrQ/T7eFvVdJkG5QIOViGvSnjYO/kUvYumm4aKnULSD9F6idwuQRc5dh6eKQEUSUqZvSVSPL6jWlEnqzVr39fHNKUXU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765467815; c=relaxed/simple; bh=ZRf+Nxr6B5lZQQ3+s5URG+X9IA/MoyIqMGU6LMeeYrM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=oDk5TkWHosJDRIjhCad/sWEUy2L3Bjq/EOA2ILrpuSZr2ujyRx8gYd5eL83QND0pLYTrM5W+q2Fv5p2QB0W1vviRY0t0tWjJvERYN+B+qGjBEmeRYxUnzkTBYlX2ulhyuUhga71zmAzpfTBOTDgDP2BvkykrZ+bD3++qVPoOnVU= 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 0D4691063; Thu, 11 Dec 2025 07:43:26 -0800 (PST) Received: from [10.163.53.200] (unknown [10.163.53.200]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 52FC93F740; Thu, 11 Dec 2025 07:43:31 -0800 (PST) Message-ID: Date: Thu, 11 Dec 2025 21:13:28 +0530 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: [PATCH] mm/vmalloc: request large order pages from buddy allocator To: Uladzislau Rezki , Ryan Roberts , "Vishal Moola (Oracle)" Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton References: <20251021194455.33351-2-vishal.moola@gmail.com> <66919a28-bc81-49c9-b68f-dd7c73395a0d@arm.com> Content-Language: en-US From: Dev Jain In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/12/25 9:09 pm, Uladzislau Rezki wrote: > On Thu, Dec 11, 2025 at 03:28:56PM +0000, Ryan Roberts wrote: >> On 10/12/2025 22:28, Vishal Moola (Oracle) wrote: >>> On Wed, Dec 10, 2025 at 01:21:22PM +0000, Ryan Roberts wrote: >>>> Hi Vishal, >>>> >>>> >>>> On 21/10/2025 20:44, Vishal Moola (Oracle) wrote: >>>>> Sometimes, vm_area_alloc_pages() will want many pages from the buddy >>>>> allocator. Rather than making requests to the buddy allocator for at >>>>> most 100 pages at a time, we can eagerly request large order pages a >>>>> smaller number of times. >>>>> >>>>> We still split the large order pages down to order-0 as the rest of the >>>>> vmalloc code (and some callers) depend on it. We still defer to the bulk >>>>> allocator and fallback path in case of order-0 pages or failure. >>>>> >>>>> Running 1000 iterations of allocations on a small 4GB system finds: >>>>> >>>>> 1000 2mb allocations: >>>>> [Baseline] [This patch] >>>>> real 46.310s real 0m34.582 >>>>> user 0.001s user 0.006s >>>>> sys 46.058s sys 0m34.365s >>>>> >>>>> 10000 200kb allocations: >>>>> [Baseline] [This patch] >>>>> real 56.104s real 0m43.696 >>>>> user 0.001s user 0.003s >>>>> sys 55.375s sys 0m42.995s >>>> I'm seeing some big vmalloc micro benchmark regressions on arm64, for which >>>> bisect is pointing to this patch. >>> Ulad had similar findings/concerns[1]. Tldr: The numbers you are seeing >>> are expected for how the test module is currently written. >> Hmm... simplistically, I'd say that either the tests are bad, in which case they >> should be deleted, or they are good, in which case we shouldn't ignore the >> regressions. Having tests that we learn to ignore is the worst of both worlds. >> > Uh.. Tests are for measure vmalloc performance and stressing. They can not be just > removed :) In some sense they are synthetic, from the other hand they allow to find > problems and bottle-necks + measure perf. You have identified regression with it :) > > I think, the problem is in the > > + 14.05% 0.11% [kernel] [k] remove_vm_area > + 11.85% 1.82% [kernel] [k] __alloc_frozen_pages_noprof > + 10.91% 0.36% [kernel] [k] __get_vm_area_node > + 10.60% 7.58% [kernel] [k] insert_vmap_area > + 10.02% 4.67% [kernel] [k] get_page_from_freelist > > > get_page_from_freelist() call. With a patch it adds 10% of cycles on > top whereas without patch i do not see the symbol at all, i.e. pages > are obtained really fast from the pcp list, not from the body. > > The question is, why high-order pages are not end-up in the pcp-cache? > I think it is due to the fact, that we split such pages and freeing them > as order-0 one. Please take a look at my RFC: https://lore.kernel.org/all/20251112110807.69958-1-dev.jain@arm.com/ You are right, we allocate large folios but then split them up and free them as basepages. In patch 2 I have proved (not rigorously) that pcp draining is one of the issues. > > Any thoughts? > > -- > Uladzislau Rezki >