From: Laura Abbott <lauraa@codeaurora.org>
To: Lin Ming <minggr@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-mm <linux-mm@kvack.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: kmalloc and uncached memory
Date: Wed, 16 Apr 2014 12:03:46 -0700 [thread overview]
Message-ID: <534ED412.1040909@codeaurora.org> (raw)
In-Reply-To: <CAF1ivSaMRj_V_NHBBDfPmNmZ+CNfCnAywfWGudpoAv_8j_FrwA@mail.gmail.com>
On 4/16/2014 11:50 AM, Lin Ming wrote:
> On Wed, Apr 16, 2014 at 11:33 AM, Laura Abbott <lauraa@codeaurora.org> wrote:
>> On 4/16/2014 11:11 AM, Lin Ming wrote:
>>> Hi Peter,
>>>
>>> I have a performance problem(on ARM board) that cpu is very bus at
>>> cache invalidation.
>>> So I'm trying to alloc an uncached memory to eliminate cache invalidation.
>>>
>>> But I also have problem with dma_alloc_coherent().
>>> If I don't use dma_alloc_coherent(), is it OK to use below code to
>>> alloc uncached memory?
>>>
>>> struct page *page;
>>> pgd_t *pgd;
>>> pud_t *pud;
>>> pmd_t *pmd;
>>> pte_t *pte;
>>> void *cpu_addr;
>>> dma_addr_t dma_addr;
>>> unsigned int vaddr;
>>>
>>> cpu_addr = kmalloc(PAGE_SIZE, GFP_KERNEL);
>>> dma_addr = pci_map_single(NULL, cpu_addr, PAGE_SIZE, (int)DMA_FROM_DEVICE);
>>> vaddr = (unsigned int)uncached->cpu_addr;
>>> pgd = pgd_offset_k(vaddr);
>>> pud = pud_offset(pgd, vaddr);
>>> pmd = pmd_offset(pud, vaddr);
>>> pte = pte_offset_kernel(pmd, vaddr);
>>> page = virt_to_page(vaddr);
>>> set_pte_ext(pte, mk_pte(page, pgprot_dmacoherent(pgprot_kernel)), 0);
>>>
>>> /* This kmalloc memory won't be freed */
>>>
>>
>> No, that will not work. lowmem pages are mapped with 1MB sections underneath
>> which cannot be (easily) changed at runtime. You really want to be using
>> dma_alloc_coherent here.
>
> For "lowmem pages", do you mean the first 16M physical memory?
> How about that if I only use highmem pages(>16M)?
>
By lowmem pages I am referring to the direct mapped kernel area. Highmem refers
to pages which do not have a permanent mapping in the kernel address space. If
you are calling kmalloc with GFP_KERNEL you will be getting a page from the lowmem
region.
What's the reason you can't use dma_alloc_coherent?
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>
next prev parent reply other threads:[~2014-04-16 19:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-16 18:11 Lin Ming
2014-04-16 18:33 ` Laura Abbott
2014-04-16 18:50 ` Lin Ming
2014-04-16 19:03 ` Laura Abbott [this message]
2014-04-16 21:28 ` Lin Ming
2014-04-16 22:43 ` Russell King - ARM Linux
2014-04-16 23:16 ` Lin Ming
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=534ED412.1040909@codeaurora.org \
--to=lauraa@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=minggr@gmail.com \
--cc=peterz@infradead.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