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 5685722B8CB for ; Wed, 24 Dec 2025 06:35:55 +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=1766558158; cv=none; b=Cuhb4r8z0DNpMcZ33Wg1jmT6Z21iof0a7rqowTpVk0Ka1gzZzjnS8+NdJBnBgWWVpe+tFVWf2bBnljL4qPb+wlbpfTmF9UDcABwpm2tdKyGKNLLWsa8xaHm6LkB7VgGmGlrkdhVTGlwLsQqJ2d66jhucPDlm6kNoYpJwPUV+oZg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766558158; c=relaxed/simple; bh=mUgpsQDDZmqdgefQXJolbrbepqezq8aiXcS28yJ7whw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Sl4ll/Kqr9htBdhC0UpHnDWrNeejJvkwbyhwZaylf1w0PtoaTGj1agUoilR6R+B784wa+ADBcfupmOXXaLC63tMdaWLhOhqinpHfWN44nW+SpBIw9lOXfb+T7MP8y9DS4ypXfXVKQI1hrhuFpaiPLyETz/a9kVIrU5nr/i0wdpM= 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 29C7E339; Tue, 23 Dec 2025 22:35:48 -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 E06943F5A1; Tue, 23 Dec 2025 22:35:52 -0800 (PST) Message-ID: <31e0d55f-b4a3-4b4c-8018-82d76c429d7b@arm.com> Date: Wed, 24 Dec 2025 12:05:49 +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 2/2] mm/vmalloc: Add attempt_larger_order_alloc parameter To: Ryan Roberts , Uladzislau Rezki Cc: linux-mm@kvack.org, Andrew Morton , Vishal Moola , Baoquan He , LKML References: <20251216211921.1401147-1-urezki@gmail.com> <20251216211921.1401147-2-urezki@gmail.com> <6ca6e796-cded-4221-b1f8-92176a80513e@arm.com> <0f69442d-b44e-4b30-b11e-793511db9f1e@arm.com> <3d2fd706-917e-4c83-812b-73531a380275@arm.com> <8490ce0f-ef8d-4f83-8fe6-fd8ac21a4c75@arm.com> Content-Language: en-US From: Dev Jain In-Reply-To: <8490ce0f-ef8d-4f83-8fe6-fd8ac21a4c75@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 18/12/25 5:23 pm, Ryan Roberts wrote: > On 18/12/2025 04:55, Dev Jain wrote: >> On 17/12/25 8:50 pm, Ryan Roberts wrote: >>> On 17/12/2025 12:02, Uladzislau Rezki wrote: >>>>> On 16/12/2025 21:19, Uladzislau Rezki (Sony) wrote: >>>>>> Introduce a module parameter to enable or disable the large-order >>>>>> allocation path in vmalloc. High-order allocations are disabled by >>>>>> default so far, but users may explicitly enable them at runtime if >>>>>> desired. >>>>>> >>>>>> High-order pages allocated for vmalloc are immediately split into >>>>>> order-0 pages and later freed as order-0, which means they do not >>>>>> feed the per-CPU page caches. As a result, high-order attempts tend >>>>>> to bypass the PCP fastpath and fall back to the buddy allocator that >>>>>> can affect performance. >>>>>> >>>>>> However, when the PCP caches are empty, high-order allocations may >>>>>> show better performance characteristics especially for larger >>>>>> allocation requests. >>>>> I wonder if a better solution would be "allocate order-0 if available in pcp, >>>>> else try large order, else fallback to order-0" Could that provide the best of >>>>> all worlds without needing a configuration knob? >>>>> >>>> I am not sure, to me it looks like a bit odd. >>> Perhaps it would feel better if it was generalized to "first try allocation from >>> PCP list, highest to lowest order, then try allocation from the buddy, highest >>> to lowest order"? >>> >>>> Ideally it would be >>>> good just free it as high-order page and not order-0 peaces. >>> Yeah perhaps that's better. How about something like this (very lightly tested >>> and no performance results yet): >>> >>> (And I should admit I'm not 100% sure it is safe to call free_frozen_pages() >>> with a contiguous run of order-0 pages, but I'm not seeing any warnings or >>> memory leaks when running mm selftests...) >> Wow I wasn't aware that we can do this. I see that free_hotplug_page_range() in >> arm64/mmu.c already does this - it computes order from size and passes it to >> __free_pages(). > Hmm that looks dodgy to me. But I'm not sure I actually understand what is going > on... I think this is fine. This function frees either the altmap (in which no struct page is freed), or the array of struct pages in the vmemmap: free_map_bootmem -> vmmemap_free (altmap=NULL) -> unmap_hotplug_range(free_mapped=true, altmap=NULL) -> ultimately __free_pages. free_map_bootmem is called from section_deactivate, and takes in a virtual address corresponding to the vmemmap struct pages. This virtual address is retrieved from sparse_decode_mem_map (note that the return value of this function is misleading).