linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Michal Nazarewicz" <mina86@mina86.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>, Mel Gorman <mel@csn.ul.ie>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org, linux-mm@kvack.org,
	linaro-mm-sig@lists.linaro.org,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Russell King <linux@arm.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Ankita Garg <ankita@in.ibm.com>,
	Daniel Walker <dwalker@codeaurora.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Jesse Barker <jesse.barker@linaro.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Shariq Hasnain <shariq.hasnain@linaro.org>,
	Chunsang Jeong <chunsang.jeong@linaro.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>
Subject: Re: [PATCH 6/9] drivers: add Contiguous Memory Allocator
Date: Mon, 24 Oct 2011 12:39:29 -0700	[thread overview]
Message-ID: <op.v3vfj30d3l0zgt@mpn-glaptop> (raw)
In-Reply-To: <20111018134321.GE6660@csn.ul.ie>

> On Thu, Oct 06, 2011 at 03:54:46PM +0200, Marek Szyprowski wrote:
>> +static unsigned long __init __cma_early_get_total_pages(void)
>> +{
>> +	struct memblock_region *reg;
>> +	unsigned long total_pages = 0;
>> +
>> +	/*
>> +	 * We cannot use memblock_phys_mem_size() here, because
>> +	 * memblock_analyze() has not been called yet.
>> +	 */
>> +	for_each_memblock(memory, reg)
>> +		total_pages += memblock_region_memory_end_pfn(reg) -
>> +			       memblock_region_memory_base_pfn(reg);
>> +	return total_pages;
>> +}
>> +

On Tue, 18 Oct 2011 06:43:21 -0700, Mel Gorman <mel@csn.ul.ie> wrote:
> Is this being called too early yet? What prevents you seeing up the CMA
> regions after the page allocator is brought up for example? I understand
> that there is a need for the memory to be coherent so maybe that is the
> obstacle.

Another reason is that we want to be sure that we can get given range of pages.
After page allocator is set-up, someone could allocate a non-movable page from
the range that interests us and that wouldn't be nice for us.

>> +struct page *dma_alloc_from_contiguous(struct device *dev, int count,
>> +				       unsigned int align)
>> +{
>> +	struct cma *cma = get_dev_cma_area(dev);
>> +	unsigned long pfn, pageno;
>> +	int ret;
>> +
>> +	if (!cma)
>> +		return NULL;
>> +
>> +	if (align > CONFIG_CMA_ALIGNMENT)
>> +		align = CONFIG_CMA_ALIGNMENT;
>> +
>> +	pr_debug("%s(cma %p, count %d, align %d)\n", __func__, (void *)cma,
>> +		 count, align);
>> +
>> +	if (!count)
>> +		return NULL;
>> +
>> +	mutex_lock(&cma_mutex);
>> +
>> +	pageno = bitmap_find_next_zero_area(cma->bitmap, cma->count, 0, count,
>> +					    (1 << align) - 1);
>> +	if (pageno >= cma->count) {
>> +		ret = -ENOMEM;
>> +		goto error;
>> +	}
>> +	bitmap_set(cma->bitmap, pageno, count);
>> +
>> +	pfn = cma->base_pfn + pageno;
>> +	ret = alloc_contig_range(pfn, pfn + count, 0, MIGRATE_CMA);
>> +	if (ret)
>> +		goto free;
>> +

> If alloc_contig_range returns failure, the bitmap is still set. It will
> never be freed so now the area cannot be used for CMA allocations any
> more.

bitmap is cleared at the “free:” label.

>> +	mutex_unlock(&cma_mutex);
>> +
>> +	pr_debug("%s(): returned %p\n", __func__, pfn_to_page(pfn));
>> +	return pfn_to_page(pfn);
>> +free:
>> +	bitmap_clear(cma->bitmap, pageno, count);
>> +error:
>> +	mutex_unlock(&cma_mutex);
>> +	return NULL;
>> +}


>> +int dma_release_from_contiguous(struct device *dev, struct page *pages,
>> +				int count)
>> +{
>> +	struct cma *cma = get_dev_cma_area(dev);
>> +	unsigned long pfn;
>> +
>> +	if (!cma || !pages)
>> +		return 0;
>> +
>> +	pr_debug("%s(page %p)\n", __func__, (void *)pages);
>> +
>> +	pfn = page_to_pfn(pages);
>> +
>> +	if (pfn < cma->base_pfn || pfn >= cma->base_pfn + cma->count)
>> +		return 0;
>> +
>> +	mutex_lock(&cma_mutex);
>> +
>> +	bitmap_clear(cma->bitmap, pfn - cma->base_pfn, count);
>> +	free_contig_pages(pfn, count);
>> +
>> +	mutex_unlock(&cma_mutex);
>
> It feels like the mutex could be a lot lighter here. If the bitmap is
> protected by a spinlock, it would only need to be held while the bitmap
> was being cleared. free the contig pages outside the spinlock and clear
> the bitmap afterwards.
>
> It's not particularly important as the scalability of CMA is not
> something to be concerned with at this point.

Mutex is used also to protect the core operations, ie. isolating pages
and such.  This is because two CMA calls may want to work on the same
pageblock and we have to prevent that from happening.

We could add the spinlock for protecting the bitmap but we will still
need mutex for other uses.

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz    (o o)
ooo +----<email/xmpp: mpn@google.com>--------------ooO--(_)--Ooo--

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-10-24 19:39 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-06 13:54 [PATCHv16 0/9] " Marek Szyprowski
2011-10-06 13:54 ` [PATCH 1/9] mm: move some functions from memory_hotplug.c to page_isolation.c Marek Szyprowski
2011-10-14 23:23   ` Andrew Morton
2011-10-18 12:05   ` Mel Gorman
2011-10-06 13:54 ` [PATCH 2/9] mm: alloc_contig_freed_pages() added Marek Szyprowski
2011-10-14 23:29   ` Andrew Morton
2011-10-16  8:01     ` Michal Nazarewicz
2011-10-16  8:31       ` Andrew Morton
2011-10-16  9:39         ` Michal Nazarewicz
2011-10-17 12:21     ` Marek Szyprowski
2011-10-17 18:39       ` Andrew Morton
2011-10-18 12:21   ` Mel Gorman
2011-10-18 17:26     ` Michal Nazarewicz
2011-10-18 17:48       ` Dave Hansen
2011-10-18 18:00         ` Michal Nazarewicz
2011-10-21 10:06       ` Mel Gorman
2011-10-24  1:00         ` Michal Nazarewicz
2011-10-24  4:05     ` Michal Nazarewicz
2011-10-24  4:05     ` Michal Nazarewicz
2011-10-24  4:05     ` Michal Nazarewicz
2011-10-24  4:05     ` Michal Nazarewicz
2011-11-01 15:04       ` Mel Gorman
2011-11-01 18:06         ` Michal Nazarewicz
2011-11-01 18:47           ` Mel Gorman
2011-10-06 13:54 ` [PATCH 3/9] mm: alloc_contig_range() added Marek Szyprowski
2011-10-14 23:35   ` Andrew Morton
2011-10-18 12:38   ` Mel Gorman
2011-10-06 13:54 ` [PATCH 4/9] mm: MIGRATE_CMA migration type added Marek Szyprowski
2011-10-14 23:38   ` Andrew Morton
2011-10-18 13:08   ` Mel Gorman
2011-10-24 19:32     ` Michal Nazarewicz
2011-10-27  9:10       ` Michal Nazarewicz
2011-10-06 13:54 ` [PATCH 5/9] mm: MIGRATE_CMA isolation functions added Marek Szyprowski
2011-10-06 13:54 ` [PATCH 6/9] drivers: add Contiguous Memory Allocator Marek Szyprowski
2011-10-14 23:57   ` Andrew Morton
2011-10-16 10:08     ` Russell King - ARM Linux
2011-10-18 13:43   ` Mel Gorman
2011-10-24 19:39     ` Michal Nazarewicz [this message]
2011-11-04 10:41     ` Marek Szyprowski
2011-10-06 13:54 ` [PATCH 7/7] ARM: integrate CMA with DMA-mapping subsystem Marek Szyprowski
2011-10-06 14:18   ` Marek Szyprowski
2011-10-15  0:03   ` Andrew Morton
2011-10-06 13:54 ` [PATCH 7/9] X86: " Marek Szyprowski
2011-10-06 13:54 ` [PATCH 8/9] ARM: " Marek Szyprowski
2011-10-14  4:33   ` [Linaro-mm-sig] " Subash Patel
2011-10-14  9:14     ` Marek Szyprowski
2011-10-06 13:54 ` [PATCH 9/9] ARM: Samsung: use CMA for 2 memory banks for s5p-mfc device Marek Szyprowski
2011-10-07 16:27 ` [PATCHv16 0/9] Contiguous Memory Allocator Arnd Bergmann
2011-10-10  6:58   ` [Linaro-mm-sig] " Ohad Ben-Cohen
2011-10-10 12:02     ` Clark, Rob
2011-10-10 22:56   ` Andrew Morton
2011-10-11  6:57     ` Marek Szyprowski
2011-10-11 13:52     ` Arnd Bergmann
2011-10-14 23:19       ` Andrew Morton
2011-10-15 14:24         ` Arnd Bergmann
2011-10-10 12:07 ` [Linaro-mm-sig] " Maxime Coquelin
2011-10-11  7:17   ` Marek Szyprowski
2011-10-11  7:30     ` Maxime Coquelin
2011-10-11 10:50       ` Marek Szyprowski
2011-10-11 11:25         ` Maxime Coquelin
2011-10-11 13:05           ` Marek Szyprowski
2011-10-12 11:08       ` [PATCH] fixup: mm: alloc_contig_range: increase min_free_kbytes during allocation Marek Szyprowski
2011-10-12 13:01         ` Maxime Coquelin
  -- strict thread matches above, loose matches on Subject: below --
2011-08-12 10:58 [PATCHv14 0/9] Contiguous Memory Allocator Marek Szyprowski
2011-08-12 10:58 ` [PATCH 6/9] drivers: add " Marek Szyprowski

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=op.v3vfj30d3l0zgt@mpn-glaptop \
    --to=mina86@mina86.com \
    --cc=akpm@linux-foundation.org \
    --cc=ankita@in.ibm.com \
    --cc=arnd@arndb.de \
    --cc=chunsang.jeong@linaro.org \
    --cc=corbet@lwn.net \
    --cc=dave@linux.vnet.ibm.com \
    --cc=dwalker@codeaurora.org \
    --cc=jesse.barker@linaro.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@arm.linux.org.uk \
    --cc=m.szyprowski@samsung.com \
    --cc=mel@csn.ul.ie \
    --cc=shariq.hasnain@linaro.org \
    /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