linux-kernel - Re: [PATCH] mm/cma: print total and used pages in cma

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <167acb82-1368-4c8e-89bd-8dbe4877d5bb@redhat.com>
Date: Sat, 16 Aug 2025 09:49:52 +0200
From: David Hildenbrand <david@...hat.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Xiang Gao <gxxa03070307@...il.com>, lorenzo.stoakes@...cle.com,
 Liam.Howlett@...cle.com, vbabka@...e.cz, rppt@...nel.org, surenb@...gle.com,
 mhocko@...e.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 gaoxiang17 <gaoxiang17@...omi.com>
Subject: Re: [PATCH] mm/cma: print total and used pages in cma_alloc()

On 16.08.25 09:34, Andrew Morton wrote:
> On Sat, 16 Aug 2025 08:56:47 +0200 David Hildenbrand <david@...hat.com> wrote:
> 
>> On 16.08.25 08:45, Andrew Morton wrote:
>>> On Sat, 16 Aug 2025 08:27:39 +0200 David Hildenbrand <david@...hat.com> wrote:
>>>
>>>>> @@ -858,8 +869,8 @@ static struct page *__cma_alloc(struct cma *cma, unsigned long count,
>>>>>     	if (!cma || !cma->count)
>>>>>     		return page;
>>>>>     
>>>>> -	pr_debug("%s(cma %p, name: %s, count %lu, align %d)\n", __func__,
>>>>> -		(void *)cma, cma->name, count, align);
>>>>> +	pr_debug("%s(cma %p, name: %s, total pages: %lu, used pages: %lu, request pages: %lu, align %d)\n",
>>>>> +		__func__, (void *)cma, cma->name, cma->count, cma_get_used_pages(cma), count, align);
>>>>
>>>> 		^ one space missing for proper indentation.
>>>>
>>>> But doing another spinlock cycle just for debugging purposes? That does
>>>> not feel right, sorry.
>>>
>>> If we're calling pr_debug() frequently enough for this to matter, we
>>> have other problems!
>>
>> We call it for each and every actual CMA allocation? I really don't see
>> why we want to just randomly make CMA allocation latency worse.
> 
> pr_debug() is 12 million times more expensive than a spin_lock()!
> 
>> Is the existing pr_debug() a problem? Maybe. But who actually has debug
>> messages enabled in any sane setup?
> 
> Nobody, clearly.  If anyone enabled pr_debug() in here, they'd
> immediately have to remove those statements to get any work done.  Kill
> it.

I just learned that pr_debug() on a !CONFIG_DEBUG kernel translates to 
no_printk(), which is just a mostly-empty macro that doesn't really use 
any of the parameters.

I would assume the cma_get_used_pages() would get completely optimized 
out in that case.

So, I don't care, but ... moving to tracing seems much more reasonable.

-- 
Cheers

David / dhildenb