From: Stefan Strogin <stefan.strogin@gmail.com>
To: Michal Nazarewicz <mina86@mina86.com>,
"Stefan I. Strogin" <s.strogin@partner.samsung.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
aneesh.kumar@linux.vnet.ibm.com,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Pintu Kumar <pintu.k@samsung.com>,
Weijie Yang <weijie.yang@samsung.com>,
Laura Abbott <lauraa@codeaurora.org>, Hui Zhu <zhuhui@xiaomi.com>,
Minchan Kim <minchan@kernel.org>,
Dyasly Sergey <s.dyasly@samsung.com>,
Vyacheslav Tyrtov <v.tyrtov@samsung.com>,
Stefan Strogin <stefan.strogin@gmail.com>
Subject: Re: [PATCH 2/3] mm: cma: introduce /proc/cmainfo
Date: Mon, 29 Dec 2014 15:09:58 +0100 [thread overview]
Message-ID: <54A160B6.5030605@gmail.com> (raw)
In-Reply-To: <xa1tzjaaz9f9.fsf@mina86.com>
Thanks for review MichaA?,
On 12/26/2014 07:02 PM, Michal Nazarewicz wrote:
> On Fri, Dec 26 2014, "Stefan I. Strogin" <s.strogin@partner.samsung.com> wrote:
>> /proc/cmainfo contains a list of currently allocated CMA buffers for every
>> CMA area when CONFIG_CMA_DEBUG is enabled.
>>
>> Format is:
>>
>> <base_phys_addr> - <end_phys_addr> (<size> kB), allocated by <PID>\
>> (<command name>), latency <allocation latency> us
>> <stack backtrace when the buffer had been allocated>
>>
>> Signed-off-by: Stefan I. Strogin <s.strogin@partner.samsung.com>
>> ---
>> mm/cma.c | 202 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 202 insertions(+)
>>
>> diff --git a/mm/cma.c b/mm/cma.c
>> index a85ae28..ffaea26 100644
>> --- a/mm/cma.c
>> +++ b/mm/cma.c
>> @@ -347,6 +372,86 @@ err:
>> return ret;
>> }
>>
>> +#ifdef CONFIG_CMA_DEBUG
>> +/**
>> + * cma_buffer_list_add() - add a new entry to a list of allocated buffers
>> + * @cma: Contiguous memory region for which the allocation is performed.
>> + * @pfn: Base PFN of the allocated buffer.
>> + * @count: Number of allocated pages.
>> + * @latency: Nanoseconds spent to allocate the buffer.
>> + *
>> + * This function adds a new entry to the list of allocated contiguous memory
>> + * buffers in a CMA area. It uses the CMA area specificated by the device
>> + * if available or the default global one otherwise.
>> + */
>> +static int cma_buffer_list_add(struct cma *cma, unsigned long pfn,
>> + int count, s64 latency)
>> +{
>> + struct cma_buffer *cmabuf;
>> + struct stack_trace trace;
>> +
>> + cmabuf = kmalloc(sizeof(struct cma_buffer), GFP_KERNEL);
>
> cmabuf = kmalloc(sizeof *cmabuf, GFP_KERNEL);
cmabuf = kmalloc(sizeof(*cmabuf), GFP_KERNEL);
>
>> + if (!cmabuf)
>> + return -ENOMEM;
>> +
>> + trace.nr_entries = 0;
>> + trace.max_entries = ARRAY_SIZE(cmabuf->trace_entries);
>> + trace.entries = &cmabuf->trace_entries[0];
>> + trace.skip = 2;
>> + save_stack_trace(&trace);
>> +
>> + cmabuf->pfn = pfn;
>> + cmabuf->count = count;
>> + cmabuf->pid = task_pid_nr(current);
>> + cmabuf->nr_entries = trace.nr_entries;
>> + get_task_comm(cmabuf->comm, current);
>> + cmabuf->latency = (unsigned int) div_s64(latency, NSEC_PER_USEC);
>> +
>> + mutex_lock(&cma->list_lock);
>> + list_add_tail(&cmabuf->list, &cma->buffers_list);
>> + mutex_unlock(&cma->list_lock);
>> +
>> + return 0;
>> +}
>> +
>> +/**
>> + * cma_buffer_list_del() - delete an entry from a list of allocated buffers
>> + * @cma: Contiguous memory region for which the allocation was performed.
>> + * @pfn: Base PFN of the released buffer.
>> + *
>> + * This function deletes a list entry added by cma_buffer_list_add().
>> + */
>> +static void cma_buffer_list_del(struct cma *cma, unsigned long pfn)
>> +{
>> + struct cma_buffer *cmabuf;
>> +
>> + mutex_lock(&cma->list_lock);
>> +
>> + list_for_each_entry(cmabuf, &cma->buffers_list, list)
>> + if (cmabuf->pfn == pfn) {
>> + list_del(&cmabuf->list);
>> + kfree(cmabuf);
>> + goto out;
>> + }
>
> You do not have guarantee that CMA deallocations will match allocations
> exactly. User may allocate CMA region and then free it chunks. I'm not
> saying that the debug code must handle than case but at least I would
> like to see a comment describing this shortcoming.
Thanks, I'll fix it. If a number of released pages is less than there
were allocated then the list entry shouldn't be deleted, but it's fields
should be updated.
>
>> @@ -361,11 +466,15 @@ struct page *cma_alloc(struct cma *cma, int count, unsigned int align)
>> unsigned long mask, offset, pfn, start = 0;
>> unsigned long bitmap_maxno, bitmap_no, bitmap_count;
>> struct page *page = NULL;
>> + struct timespec ts1, ts2;
>> + s64 latency;
>> int ret;
>>
>> if (!cma || !cma->count)
>> return NULL;
>>
>> + getnstimeofday(&ts1);
>> +
>
> If CMA_DEBUG is disabled, you waste time on measuring latency. Either
> use #ifdef or IS_ENABLED, e.g.:
>
> if (IS_ENABLED(CMA_DEBUG))
> getnstimeofday(&ts1);
Obviously! :)
>
>> @@ -413,6 +522,19 @@ struct page *cma_alloc(struct cma *cma, int count, unsigned int align)
>> start = bitmap_no + mask + 1;
>> }
>>
>> + getnstimeofday(&ts2);
>> + latency = timespec_to_ns(&ts2) - timespec_to_ns(&ts1);
>> +
>> + if (page) {
>
> if (IS_ENABLED(CMA_DEBUG) && page) {
> getnstimeofday(&ts2);
> latency = timespec_to_ns(&ts2) - timespec_to_ns(&ts1);
>
>> + ret = cma_buffer_list_add(cma, pfn, count, latency);
>
> You could also change cma_buffer_list_add to take ts1 as an argument
> instead of latency and then latency calculating would be hidden inside
> of that function. Initialising ts1 should still be guarded with
> IS_ENABLED of course.
if (IS_ENABLED(CMA_DEBUG) && page) {
getnstimeofday(&ts2);
latency = timespec_to_ns(&ts2) - timespec_to_ns(&ts1);
It seem to me this variant is better readable, thanks.
>
>> + if (ret) {
>> + pr_warn("%s(): cma_buffer_list_add() returned %d\n",
>> + __func__, ret);
>> + cma_release(cma, page, count);
>> + page = NULL;
>
> Harsh, but ok, if you want.
Excuse me, maybe you could suggest how to make a nicer fallback?
Or sure OK?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-12-29 14:09 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-26 14:39 [PATCH 0/3] mm: cma: /proc/cmainfo Stefan I. Strogin
2014-12-26 14:39 ` [PATCH 1/3] stacktrace: add seq_print_stack_trace() Stefan I. Strogin
2014-12-27 7:04 ` SeongJae Park
2014-12-26 14:39 ` [PATCH 2/3] mm: cma: introduce /proc/cmainfo Stefan I. Strogin
2014-12-26 16:02 ` Michal Nazarewicz
2014-12-29 14:09 ` Stefan Strogin [this message]
2014-12-29 17:26 ` Michal Nazarewicz
2014-12-31 1:14 ` Gioh Kim
2015-01-23 12:32 ` Stefan Strogin
2014-12-29 21:11 ` Laura Abbott
2015-01-21 14:18 ` Stefan Strogin
2014-12-30 4:38 ` Joonsoo Kim
2015-01-22 15:35 ` Stefan Strogin
2015-01-23 6:35 ` Joonsoo Kim
2014-12-26 14:39 ` [PATCH 3/3] cma: add functions to get region pages counters Stefan I. Strogin
2014-12-26 16:10 ` Michal Nazarewicz
2014-12-27 7:18 ` SeongJae Park
2014-12-29 5:56 ` Safonov Dmitry
2014-12-29 14:12 ` Stefan Strogin
2014-12-30 2:26 ` Joonsoo Kim
2014-12-30 14:41 ` Michal Nazarewicz
2014-12-30 14:46 ` Safonov Dmitry
2014-12-29 2:36 ` [PATCH 0/3] mm: cma: /proc/cmainfo Minchan Kim
2014-12-29 19:52 ` Laura Abbott
2014-12-30 4:47 ` Minchan Kim
2014-12-30 22:00 ` Laura Abbott
2014-12-31 0:25 ` Minchan Kim
2015-01-21 13:52 ` Stefan Strogin
2015-01-23 6:33 ` Joonsoo Kim
2014-12-31 0:58 ` Gioh Kim
2014-12-31 2:18 ` Minchan Kim
2014-12-31 2:45 ` Gioh Kim
2014-12-31 6:47 ` Namhyung Kim
2014-12-31 7:32 ` Minchan Kim
2015-01-09 14:19 ` Steven Rostedt
2015-01-09 14:35 ` Steven Rostedt
2015-01-13 2:27 ` Minchan Kim
2015-01-02 5:11 ` Pavel Machek
2015-01-22 15:44 ` Stefan Strogin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54A160B6.5030605@gmail.com \
--to=stefan.strogin@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=lauraa@codeaurora.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=m.szyprowski@samsung.com \
--cc=mina86@mina86.com \
--cc=minchan@kernel.org \
--cc=pintu.k@samsung.com \
--cc=s.dyasly@samsung.com \
--cc=s.strogin@partner.samsung.com \
--cc=v.tyrtov@samsung.com \
--cc=weijie.yang@samsung.com \
--cc=zhuhui@xiaomi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).