From: Laura Abbott <lauraa@codeaurora.org>
To: Gregory Fong <gregory.0xf0@gmail.com>, linux-mm@kvack.org
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
Michal Nazarewicz <mina86@mina86.com>,
Andrew Morton <akpm@linux-foundation.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Weijie Yang <weijie.yang@samsung.com>,
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] mm: cma: add functions for getting allocation info
Date: Thu, 18 Dec 2014 09:00:37 -0800 [thread overview]
Message-ID: <54930835.8020009@codeaurora.org> (raw)
In-Reply-To: <1418854236-25140-1-git-send-email-gregory.0xf0@gmail.com>
On 12/17/2014 2:10 PM, Gregory Fong wrote:
> These functions allow for retrieval of information on what is allocated from
> within a given CMA region. It can be useful to know the number of distinct
> contiguous allocations and where in the region those allocations are located.
>
> Based on an initial version by Marc Carino <marc.ceeeee@gmail.com> in a driver
> that used the CMA bitmap directly; this instead moves the logic into the core
> CMA API.
>
> Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
> ---
> This has been really useful for us to determine allocation information for a
> CMA region. We have had a separate driver that might not be appropriate for
> upstream, but allowed using a user program to run CMA unit tests to verify that
> allocations end up where they we would expect. This addition would allow for
> that without needing to expose the CMA bitmap. Wanted to put this out there to
> see if anyone else would be interested, comments and suggestions welcome.
>
Information is definitely useful but I'm not sure how it's intended to
be used. Do you have a sample usage of these APIs? Another option might
be to just add regular debugfs support for each of the regions instead
of just calling out to a separate driver.
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Laura Abbott <lauraa@codeaurora.org>
To: Gregory Fong <gregory.0xf0@gmail.com>, linux-mm@kvack.org
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
Michal Nazarewicz <mina86@mina86.com>,
Andrew Morton <akpm@linux-foundation.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Weijie Yang <weijie.yang@samsung.com>,
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] mm: cma: add functions for getting allocation info
Date: Thu, 18 Dec 2014 09:00:37 -0800 [thread overview]
Message-ID: <54930835.8020009@codeaurora.org> (raw)
In-Reply-To: <1418854236-25140-1-git-send-email-gregory.0xf0@gmail.com>
On 12/17/2014 2:10 PM, Gregory Fong wrote:
> These functions allow for retrieval of information on what is allocated from
> within a given CMA region. It can be useful to know the number of distinct
> contiguous allocations and where in the region those allocations are located.
>
> Based on an initial version by Marc Carino <marc.ceeeee@gmail.com> in a driver
> that used the CMA bitmap directly; this instead moves the logic into the core
> CMA API.
>
> Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
> ---
> This has been really useful for us to determine allocation information for a
> CMA region. We have had a separate driver that might not be appropriate for
> upstream, but allowed using a user program to run CMA unit tests to verify that
> allocations end up where they we would expect. This addition would allow for
> that without needing to expose the CMA bitmap. Wanted to put this out there to
> see if anyone else would be interested, comments and suggestions welcome.
>
Information is definitely useful but I'm not sure how it's intended to
be used. Do you have a sample usage of these APIs? Another option might
be to just add regular debugfs support for each of the regions instead
of just calling out to a separate driver.
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
next prev parent reply other threads:[~2014-12-18 17:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-17 22:10 [RFC PATCH] mm: cma: add functions for getting allocation info Gregory Fong
2014-12-17 22:10 ` Gregory Fong
2014-12-18 17:00 ` Laura Abbott [this message]
2014-12-18 17:00 ` Laura Abbott
2015-02-04 23:14 ` Gregory Fong
2015-02-04 23:14 ` Gregory Fong
2014-12-18 19:20 ` Michal Nazarewicz
2014-12-18 19:20 ` Michal Nazarewicz
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=54930835.8020009@codeaurora.org \
--to=lauraa@codeaurora.org \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=gregory.0xf0@gmail.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=m.szyprowski@samsung.com \
--cc=mina86@mina86.com \
--cc=weijie.yang@samsung.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.