From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D04F72E54A2 for ; Thu, 11 Dec 2025 16:24:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765470269; cv=none; b=lyT3Jgn8vKf2osV9tD0zN7MY71ErWb1GB15xG27T9KYHiKzExokWvcKzPbf4xQwWp9wkdNmc0M5w1mYwwX3BVum3Zn7QmaNdEoTOIuagIKGibKZnwhyNzZvoBQKW/thdu2NISmc7VMtDw1McnwmEcrY93Td/nMqLaWY9e09bcss= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765470269; c=relaxed/simple; bh=EkKNMjX3UfkjzTittUosuf8+lpnf9xnuKNibSuQk8Kc=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cCxBHE1FbY8o5CZdw3fKuBXmkt9NFMi0VcXuMwoUdwwVFJLGAIV/n9D9IT6B/dA6CJyJRy1OxGewyIrmm9vHatob+9HjQptPPT3Ocy+Um+WK1xj5WLoC5eCftT0+yMGme6e3IEZW+XuhvfQDLEC04nOLF3YRi0bJWZ3WUXA9UCk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=fXLD9ZqK; arc=none smtp.client-ip=209.85.167.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fXLD9ZqK" Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-5959d9a8eceso344343e87.3 for ; Thu, 11 Dec 2025 08:24:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765470266; x=1766075066; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=gSLed+mBFt43RsbZF3UjGORuOaaX7SHPDtT6COozKyQ=; b=fXLD9ZqKSf5+bfS4MU1iU8Fr5Fk1SMGs1LgTXGhwF4H4L0ScIFKV5Usb3zGDzbdWwa lEgXEKXec5M0DNSImT2VvqgR29v6QmZSvOB22BdXBNxeuYBd9OZaXMuV/LgTzTLYqBQ/ UGoE5qjrUcrS3i6pq9rNHdZfWv3MZUIhndTUJFJhLGDtiul1fb7OWvOAGIny360kIAb3 KvE4H3pIOtp361Jb6njrIzKRiTTriLkE3xSnIqnQlbB//u1vBdY8utaMCyPaAe2N47VF Wst+5QL4rr7WZMra693mF+paEf3AzeXlD9sw6f7BrU/EVrYcx9Z4w9XW7bCuEtXnp6C2 mVZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765470266; x=1766075066; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gSLed+mBFt43RsbZF3UjGORuOaaX7SHPDtT6COozKyQ=; b=mTYPjYaKWTffRk5fQAXhkl2/t0o0ZvvuCdFz5eOAs+6ysG4NMaU6sawbZjXgfEnFuE /scOqAFf0TTxKu62B+v5xhhBGxzicKsX+9ByHWqK+KsqKSqsPkpYRYqE6SM5pc7x/SUS UZuVUvyUNMaSnvk+7D4Uo/ZPEP2Z/B1FSnj/97B9XihCEk2wBro2otS/kGvUzpuwID+4 4Dq8A3s7JILC1E+qihp2GVr7gVTakisaSosw2E0iVcWqRhBF5jwb5443ffzEAoYFFknU 3aIVjtgnURCsMpkW6WreQNdvdfVQZ2kIIHkodfgpDcnhaky5HaCwoGfyi25bGcELX+jm wbbA== X-Forwarded-Encrypted: i=1; AJvYcCXxFUNhH/lW+bLRhGzai7LmEZwXpXAyIH9SMwyfKlAbTsviv6nElqYFI/4Ah0/W8IrRB6KXCKE8Etc67Ak=@vger.kernel.org X-Gm-Message-State: AOJu0Yyp75oqCa0G7sRuYk4rDA2hgY+Pe2gzmWRTKA2yVYgpDodsPVSr eopxGG6s0euDosZ+emH1dL0WK6HnkRaeMNiwNyl6961l8ZdnDaC32dAN X-Gm-Gg: AY/fxX7sXE8cOE6ctC2ZOWLKNcjxFfglE9ia04NTZ5HWKJBkQBMro26jU4Z3U5Am1ek EaDDVzBDuipkzSeH41lJufM/V/z/yINrtEqeja22iTgmbbK6jFbCaj3HzdCbASfQyViyTwp1kSu H7jZ0LgoM1zrb+j5EwRYVQdEqEwgJGxkEiB9qZoXc9qkE5ZEbs8GpnxqXnRSUBvmZaEB5BBoC5W i33IEWKts0C3gyDsYh7dAP4RIqm7j95wSl/R3zAuIplAsgEGjXDaRYTMauf5wOLyeC8aESLBT/u zQSN9ucixmT8PWEN8OoPIHRwZGKOBs8O+OTX4rHH9xWtNpf1iSAadFr/+gTXQDeODhS/Ak3wko6 F7yTkS3pM1txhSgAxRqk4vxt8h2VtTwRchbheOH4q2QJ8zJz16dE9 X-Google-Smtp-Source: AGHT+IE+/fEVCaoWW4SPnMjiZebsBFIHj+HP3TwFpHuXc8z+Tr0SNOl8KA+vkaUer4vYgV9FqFmSpQ== X-Received: by 2002:a05:6512:23a9:b0:595:7d0c:99dc with SMTP id 2adb3069b0e04-598ee4d5a87mr2628440e87.11.1765470265674; Thu, 11 Dec 2025 08:24:25 -0800 (PST) Received: from milan ([2001:9b1:d5a0:a500::24b]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-598f2f45bbbsm978481e87.45.2025.12.11.08.24.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Dec 2025 08:24:24 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Thu, 11 Dec 2025 17:24:23 +0100 To: Dev Jain Cc: Uladzislau Rezki , Ryan Roberts , "Vishal Moola (Oracle)" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton Subject: Re: [PATCH] mm/vmalloc: request large order pages from buddy allocator Message-ID: References: <20251021194455.33351-2-vishal.moola@gmail.com> <66919a28-bc81-49c9-b68f-dd7c73395a0d@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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? -- Uladzislau Rezki