From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (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 C1F493DA5BC for ; Tue, 26 May 2026 12:07:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779797260; cv=none; b=SMVsE2O1u9uo5pRnF/YUElIk3Mz3Wd7eaURVCY+B5zn/uLhS+NyIefzBqW8o2kfdUbt3YuDqQJosjRqbGpdi7MV12SW3moL5jVsFP6Jh70l8OVtWxqpj+JZZCO4utEKfLU5WtRPwAJkSfDPag5HMJQczagauumi6kewjvfTO0E0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779797260; c=relaxed/simple; bh=TGKilWqHCNmwW2kaxE8OvKst4U2AzAghy0Me37K4aOM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=U9lJlLz1KS7TxOGZVAVozvuWS6nFu3dqdH3f4vk3eFxMF6W5nXOMHSc4sl60NsZtD/wOB7ZAAiEJvLhYEp43kzx5Tw+3i7y2aSB4F0LtwOVf8NfZ7ffO3w/shq2WN/TB0y4hr1cdjxUI4xryCCThUzqPBvqj96J0R5m1HQukjaU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=Wy9+6tn7; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="Wy9+6tn7" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4891c569cb1so10379385e9.2 for ; Tue, 26 May 2026 05:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1779797257; x=1780402057; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=HdCzA4cxs/UXVY1rBI+ynwKuOH0VRJEDWv8W0sC8Rh0=; b=Wy9+6tn7hS1LDxQKI/Pob7NfvVVxJJh3hT8V4rm7sP5Mi4l2Y0WGs4VCMfgIOE8For Kytn5FxU4eWeF9APwqWZVHKqQibIMQcPzaV/LqgdN9+byjn2ZqjPo5L2jpCLzkFC1yhH sp0bJHmYROhUKXoNudt/XBjsqYGP/5ASjcYwHwJcyhpQeAb5O8ih8AonFK59jTGsoIO1 g5ua8KgCMqfVKLy2bc+zFNibSER4cp080+mJC7pgd+u4/fc/CZLlq6zczQdgYry8gNnt LAH44Pnai7G4POWbAzdVMMrDZDilNLp+grMeq5UMk6SpbgXxRVPpGkYjFCKWyyHjHs0+ TC6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779797257; x=1780402057; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HdCzA4cxs/UXVY1rBI+ynwKuOH0VRJEDWv8W0sC8Rh0=; b=r3h7AiazFvFPKFL5cPdhiUOmGkixclAQPr/gR4E1DRQ0669bvowomxVO426uJIS3IM EpeC8d/3IJXCearHbxIxd7nojn9lw+XbRSCxkOD/1LhcJcWt2a6uCGgZG+98StGGwcUz VqclKVSJRZkzisP/nBaKTz3v2pPLxaA7aZNU9KbHOacUfKmWOWwnGQW5jzAsuNXBsV3M E7uIDRGUFlpyp4XZgAxQ5St8IXugzbR2Z1VNM82nCwsrUqQk2c/AgWfWdWtFb7IPXS2b euCWEVXz8JgyjDaBksE48hOzzPNsrix1u2o0KG8ajICQsOwLIn8RzTE2bTe+uwSX6eqT 2WVg== X-Forwarded-Encrypted: i=1; AFNElJ85u0pGtFMag7ScEgZfXVCvo3ikJ3rOp8OVFVWW5I4Z+C5tuuwkTmIJs9Cbn5GX1HS8VMwmsA3z+HeTvKI=@vger.kernel.org X-Gm-Message-State: AOJu0YzqrVzjKVfeoR12vaqD7TnRkP4bQ5uFgnIRqgoHtcZGlUL4d6Xk bE/jOPDxRVw9fucrsX7x3BAGdG0wCJjMs8NUvLhC48yi++AQKUMtXr+w1wTg02e9cYqma3mcfVA osLyw X-Gm-Gg: Acq92OFWO3Lsg2H3lMFR2Ume2QndcWoKtXPb1aomU1SvHeoS35GsSo4U5Z4i+lEPOIj PnJFDuO2zeYg8iqC5kslTm5FJlTMr7c51V7gU9/oXmNBMxwrDDzi2CH9ZqPze5tNEYd61t8L9zS HZiw8Duag/hwmBQELVdJRJKFvELKYJo9gjMuxjC06E2jk4tuOWsJOZbKcA9nxXJsqSNbtFk0T6l YWCjkdX0JdmOX2DoUTuoki2f9x4D/1b4wEdVlF6ZCGIW1fPPJGDQVZR8gGZCkibqPztAPnDc7lk 1O76ToqPb6gqExWAbV47n18GJip9eRoSBZCQRfKOyBHTiNLCiqWemhlLOsZnWd5JDw+I7oPOlq1 q9vHSBEipxefcXB+qUzT/QM/tIT1KYIkfus6XI/na1qPOV07pSiT6ZtfxoRAy8CYCplyha+9okY RBEa3f37yGI23tcBBgB4ZDPo314folYVzhkK53hUE= X-Received: by 2002:a05:600c:b96:b0:490:4923:aa3e with SMTP id 5b1f17b1804b1-4904923ab35mr126128205e9.7.1779797257109; Tue, 26 May 2026 05:07:37 -0700 (PDT) Received: from [192.168.43.36] (nat2.prg.suse.com. [195.250.132.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490452765f5sm332553945e9.5.2026.05.26.05.07.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2026 05:07:36 -0700 (PDT) Message-ID: <1dea9df9-18c2-46f5-bf47-abb3f088574b@suse.com> Date: Tue, 26 May 2026 14:07:36 +0200 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] block: partitions: replace __get_free_page() with kmalloc() To: Mike Rapoport , Christoph Hellwig , Matthew Wilcox Cc: Jens Axboe , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20260520-block-v1-1-6463dc2cf042@kernel.org> From: Vlastimil Babka Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/25/26 11:35 AM, Mike Rapoport wrote: > On Mon, May 25, 2026 at 12:16:23AM -0700, Christoph Hellwig wrote: >> >> This does, but it still fails to explain why kmalloc performs just as >> well as __get_free_page(s) these days. > > I don't think that in this case - a single allocation on the cold path - > the performance difference is even measurable. > > Nevertheless allocations from slab caches are way faster than > __get_free_page() (i.e. alloc_pages()) as it's essentially lockless > cmpxchg. Allocations that need to refill the cache do alloc_pages() with a Probably not "way faster" but the fast path is quite similar - percpu pcplist protected by spin_trylock (pages) vs sheaves with local_trylock (slab), should slightly favour slab because spinlocks are typically not inlined and local_trylock is. The main reasons for switching AFAIU would be related with the folio/memdesc conversions? If one needs just a kernel memory buffer, kmalloc() it is, even if it happens to be page size. Page allocator should be only used if you need e.g. the refcounting or anything else that struct page provides. But then in some cases the memdesc conversion would need adjustments at some point. With kmalloc() we can forget about this user. Matthew can probably state it better or even link to something authoritative? > little of slab bookkeeping overhead. >