linux-kernel - Re: [PATCH 0/3] mm: cma: /proc/cmainfo

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]

Date:	Mon, 29 Dec 2014 11:52:58 -0800
From:	Laura Abbott <lauraa@...eaurora.org>
To:	Minchan Kim <minchan@...nel.org>,
	"Stefan I. Strogin" <s.strogin@...tner.samsung.com>
CC:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Michal Nazarewicz <mina86@...a86.com>,
	aneesh.kumar@...ux.vnet.ibm.com,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Dmitry Safonov <d.safonov@...tner.samsung.com>,
	Pintu Kumar <pintu.k@...sung.com>,
	Weijie Yang <weijie.yang@...sung.com>,
	SeongJae Park <sj38.park@...il.com>,
	Hui Zhu <zhuhui@...omi.com>,
	Dyasly Sergey <s.dyasly@...sung.com>,
	Vyacheslav Tyrtov <v.tyrtov@...sung.com>
Subject: Re: [PATCH 0/3] mm: cma: /proc/cmainfo

On 12/28/2014 6:36 PM, Minchan Kim wrote:
> Hello,
>
> On Fri, Dec 26, 2014 at 05:39:01PM +0300, Stefan I. Strogin wrote:
>> Hello all,
>>
>> Here is a patch set that adds /proc/cmainfo.
>>
>> When compiled with CONFIG_CMA_DEBUG /proc/cmainfo will contain information
>> about about total, used, maximum free contiguous chunk and all currently
>> allocated contiguous buffers in CMA regions. The information about allocated
>> CMA buffers includes pid, comm, allocation latency and stacktrace at the
>> moment of allocation.
>
> It just says what you are doing but you didn't say why we need it.
> I can guess but clear description(ie, the problem what you want to
> solve with this patchset) would help others to review, for instance,
> why we need latency, why we need callstack, why we need new wheel
> rather than ftrace and so on.
>
> Thanks.
>

I've been meaning to write something like this for a while so I'm
happy to see an attempt made to fix this. I can't speak for the
author's reasons for wanting this information but there are
several reasons why I was thinking of something similar.

The most common bug reports seen internally on CMA are 1) CMA is
too slow and 2) CMA failed to allocate memory. For #1, not all
allocations may be slow so it's useful to be able to keep track
of which allocations are taking too long. For #2, migration
failure is fairly common but it's still important to rule out
a memory leak from a dma client. Seeing all the allocations is
also very useful for memory tuning (e.g. how big does the CMA
region need to be, which clients are actually allocating memory).

ftrace is certainly usable for tracing CMA allocation callers and
latency. ftrace is still only a fixed size buffer though so it's
possible for information to be lost if other logging is enabled.
For most of the CMA use cases, there is a very high cost if the
proper debugging information is not available so the more that
can be guaranteed the better.

It's also worth noting that the SLUB allocator has a sysfs
interface for showing allocation callers when CONFIG_SLUB_DEBUG
is enabled.

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/