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 A246628E571 for ; Fri, 12 Dec 2025 03:56:03 +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=1765511765; cv=none; b=jKDBTn+WDRAtZ+QSrOcMYTU4ksqRZzY9JN+HFcb0bcPbZb0m/4TslMn2H5KnFFhOCuqtc3KvgHOqOGx7QmOX3Q49FZqv0frb7NOXHQ3YkZUiEQEhD5TV7YNne+5wamUwBgpJQpcacJ+yJd/bh46IE5WpSYIqsYNBaSvKuP7yACY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765511765; c=relaxed/simple; bh=Blh+/pT+c8XOzrz2ZCuEdbG2flhnArCbRo2gkrpCPqA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=O6JwYHbIKJTKnJ1TupgPIhY+Kvx3V6t3we4T5xceQV9piqRs9dATgIhlU7QTedPbOeF6U8P6NfpUnj5XtQcAT4XClmCfm44N9b1zXRyk6jd7B5ScP+V2A8Wx+qxIMIQ/pH3IqyNhZTD9Hw09XUNsc7Bsl8tUCoXFL42k4/CUrG8= 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 930D71063; Thu, 11 Dec 2025 19:55:55 -0800 (PST) Received: from [10.164.18.59] (MacBook-Pro.blr.arm.com [10.164.18.59]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CF28B3F762; Thu, 11 Dec 2025 19:56:00 -0800 (PST) Message-ID: <9baf5ba4-fe44-4b0b-a249-5535e68068f8@arm.com> Date: Fri, 12 Dec 2025 09:25:57 +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 Cc: Ryan Roberts , "Vishal Moola (Oracle)" , 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:54 pm, Uladzislau Rezki wrote: > On Thu, Dec 11, 2025 at 09:13:28PM +0530, Dev Jain wrote: >> 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. >> > You sent out RFC 12 of NOV :-/ I have missed those two patches from you, > even though you put me into "to". > > Appreciate that you point me on your work. Let me have a look at this. > > Could you please resend RFC based on latest code-base? Yup I'll do that. I was trying to get some perf numbers from LTP - fsstress, but the variance seems to be high on the system I am testing. I would appreciate if you or someone can run some benchmarks (filesystem is what I believe would benefit). > > -- > Uladzislau Rezki >